Boring Languages Are Underrated (2015)

https://danluu.com/boring-languages/

by panic • 5 years ago

75 96 5 years ago

danluu.com

majkinetor• 5 years ago

To be pedantic, Calibre is written mostly in Python, not in Java.

ncmncm6• 5 years ago

BTW: Why is Python not a boring language? Serious question.

Related: What makes C++ a boring language?

breckenedge2• 5 years ago

It is boring now. At some point c++ and Java were exciting and revolutionary. The basic premise holds, choose technology that has widespread adoption and, to be really effective, that you’re already familiar with.

dsizzle2• 5 years ago

Where does Joel Spolsky pick on boring languages? I went looking for this and could only find him defending the use of Java/.NET https://www.joelonsoftware.com/2006/09/01/language-wars/. Of course that's an old article. (Incidentally the first result of my search was this very article.)

dnautics5• 5 years ago

He missed the mark too, throwing shade on RoR; today almost everyone on this site depends on a mission critical RoR app (GitHub) that has scaled just fine (I'm aware parts of GitHub are no longer ruby)

civilized• 5 years ago

Well, technically, the Git part of GitHub is written in C.

bdcravens3• 5 years ago

It wasn't terribly inaccurate.

"for Serious Business Stuff you really must recognize that there just isn’t a lot of experience in the world building big mission critical web systems in Ruby on Rails" - in 2006 was true

"I’m really not sure that you won’t hit scaling problems" - Twitter's issues scaling Rails are well known

"that’s not a safe choice for at least another year or six" - For many that was true. For example, prior to Bundler (released in 2010), managing dependencies was hairy.

"you’ll be buying 5 times as many boxes as the .NET guy down the hall" - Easy to throw resources at a problem now, but pre-cloud, that required some serious capex, so it wasn't a problem you take lightly. DHH himself has acknowledged Rails needs more resources, as they aren't optimizing for that problem: "Don’t get me wrong, though. I love speed. I especially love free and cheap speed. It’s just that I’m not willing to trade things that are of real, enduring value to get more of a nice-to-have once we’ve long since reached Good Enough. Things like programmer happiness, the eloquence of Ruby, and the productivity of Rails." (https://m.signalvnoise.com/ruby-has-been-fast-enough-for-13-...)

(FWIW, I'm 100% Team Rails these days, but I do think Spolsky's assessment at the time was valid)

bdcravens3• 5 years ago

in 2006 .NET was only 4 years old, quite young as far as languages/frameworks go

codesections2• 5 years ago

Where does Joel Spolsky pick on boring languages?

I wonder if TFA is thinking about some of the harsh words Spolsky had for Java (e.g., [0]). That's not a criticism of boring languages in general, but is pretty negative on one boring language.

[0] https://www.joelonsoftware.com/2005/12/29/the-perils-of-java...

dsizzle2• 5 years ago

Yeah maybe. Although that's more focused on _students_ of Java and ends up being a roundabout/backhanded _compliment_ to Java: "the language is so ergonomic I can't tell if basic students of it are smart"?

ncmncm6• 5 years ago

Apparently the only published way to contact Dan Luu is via a twitter account. So, additional notable C++ uses:

  - Gdb
  - SpaceX real-time flight control
  - All fintech (besides FPGAs)
  - Fuschia OS

Gdb and Gcc are interesting as wholly successful drama-free transitions from C.

wk_end• 5 years ago

"All" fintech? Not remotely true. Lots of fintech is written in C#, Java, Haskell, Ocaml, and more.

ncmncm6• 5 years ago

It is possible to find isolated instances of fintech in other languages.

codesections2• 5 years ago

With "more" notably including Q and other array languages — pretty much as far from "boring" as you can get

boulos• 5 years ago

Dan's email address is his name @ gmail.com [1].

[1] https://mobile.twitter.com/danluu/status/934880279772258304

moonchild• 5 years ago

All fintech

Not all. Source: personal experience.

sho• 5 years ago

All fintech

Outside of HFT and matching engines at big exchanges exactly what do you think is in C++? Because I don't think what you said is remotely true. C++, if used at all, would be reserved for the smallest, fastest spinning cog, everything else (95%+) in a more human-scalable tech stack.

noir_lord2• 5 years ago

Not even sure that that super tight inner loop stuff would be in C++ - I think C still rules what hasn't been moved to FPGA's/ASICs.

fiddlerwoaroof• 5 years ago

The footnote about Sapir-Whorf slightly misses the point, I think: I found learning Haskell useful because it made it impossible to write programs the way I was used to on Python. So, I _had_ to learn to think in the paradigm it uses. I’ve mostly written Java and JS/TS for pay, but I now have experience with a whole new way of designing programs that is relatively useful.

sgeisenh• 5 years ago

I would like the definition of "boring".

Most of my day job is spent reading C++ (I write some, too) and it is more terrifying than boring. Understanding when certain errors can (and do) occur and when to optimize for performance over readability is really, really hard.

I believe that Rust, Go and TypeScript have gained a lot of popularity because they are boring to read. Even OCaml has gained a ton of popularity because it is boring to read.

C, C++, python and JavaScript: not boring to read, you constantly need to be on your toes.

Jtsummers• 5 years ago

It's partially covered in the first link on the page: https://mcfunley.com/choose-boring-technology.

A specific quality described there would be languages that have fewer unknown unknowns, a lack of surprises. C, C++, Java (the three he picks) have relatively few surprises. Either by virtue of design (here I'd say both C and Java) or total industry experience with the language (C++, C, Java). Ubiquity might be another consideration. A lot of other languages could probably be added to the list on that criteria.

Another would be how common it is, especially for a particular domain. In my field (embedded, safety critical, real-time) it would seem like Rust would be a great choice, but it's not common and there are both technical and logistical hurdles preventing its use (for fielding, at least, for proofs of concept it's viable and that could lead to its use in fielded systems later). I'm constrained to C, C++, and maybe Ada. Fortran has been phased out, but would've been one of the boring languages for this domain up to about 20 years ago (for a new project).

nielsbot• 5 years ago

Not really what you meant, but I personally have never found C++ programming to be without surprises of some sort: easy to make mistakes which are hard to find, having to agree on which C++ features/paradigms to adopt in your codebase, willy-nilly exceptions, constant appearance of new language features, etc.

smackeyacky• 5 years ago

I think C++ is full of surprises, especially inersection of where macros and class templates collide.

I don't think I ever saw more surprising behaviour from a language than c++, although most of the horrible surprises were cfront related and I hope they are gone now.

baby• 5 years ago

I agree that Golang is more in the boring side. OCaml, Rust, and ts though?

toastal• 5 years ago

Anecdotely, I read by first top-to-bottom OCaml source last month and it made me question what I had been writing (PureScript and a bit of Haskell) because it was so simple and easy to read by not getting into the type classes weeds. It has just the right amount of features, like ADTs and pattern matching, without too much for the average reader. It's not as terse, but that can be an advantage.

Zababa6• 5 years ago

From my experience with TS, it usually goes from JS with types (what I usually write) to something that looks like a class-based language like Java or C# (for example Angular). Most of the decisions in TS make sense if you consider that the goal is to be able to statically type the existing JS ecosystem. It's boring compared to some of the alternatives like Resript or Elm in that it's just another layer on JS rather than a new way of doing things.

For Rust, it's another kind of boring. The language may be new, but lots of libraries are there. If you want to do something, you can usually pull a few libaries, read the (usually great) documentation, write some glue code and your problem is solved. In that way the experience is usually close to Go.

OCaml is another kind of boring. It's less "crazy" than something like Haskell or Scala. It's really stable, code from 20+ years ago can compile just fine. You can write most of your code as plain functions and data structures but you still have the object and module systems if you need them. Even when they bring big changes to the language such as removing the GIL and adding multicore, they work hard to make sure that existing code won't break and single core performance won't suffer too much.

My point with all of that is that boring means different things to different people. People identities are stongly tied to the language they use (I talk a bit more about that here https://news.ycombinator.com/item?id=28256211). People talking about "boring" languages is probably a reaction to people talking about "exciting" languages and trying their identities to them. Someone says he learned Haskell, I feel inferior because he knows Haskell and JS and I only know JS, but I can counter that by saying that I "focus on the product" and "solve real problems" with "boring languages".

I like the irony that on the same website, there is an article about "Keeping your identity small" (http://www.paulgraham.com/identity.html) and how people that don't use Lisp can't even understand why Lisp is better (http://www.paulgraham.com/avg.html).

zinekeller• 5 years ago

I think that when he means "boring", it's something that is relatively mature and the pitfalls are well-known. Despite C/C++ being (in my own opinion) dangerous to use and relatively hard-to-maintain, you already know where are the failure points etc. While Rust and Go (for example) are now a bit more mature, there are still some unknowns and (solvable) limitations (for example compilers in non-ARM embedded systems).

vp89895• 5 years ago

Agreed. Some new languages actually have the inherent capacity to be much more boring than incumbents, once the requisite work has been done to flesh out their ecosystems and make them familiar to people.

d3nj4l• 5 years ago

I agree with this - I don't think there's any way to define "boring" that doesn't fall apart after examination. Is it age? Lisp (whichever flavour you like) has been around forever and I'd wager very few consider it boring, likewise for Haskell and the MLs. Ecosystem? ditto. Predictability? The MLs are probably better here than C++, as you mention. Real world usage? Gee, we're talking about this on a website written in a Lisp!

It seems to me that "boring" is an reverse-pejorative for "C/C++/Java" - which I think is ridiculous, because even in 2015 Ruby and Python should've assumed "boring" status by all means, and the author even sort of acknowledges this! I understand the word as used in "Use Boring Tech" has a certain instinctive resonance to most people, but in all usages I think we should replace it with familiar. What's familiar varies from person to person, team to team, and also doesn't serve as a pejorative to anything else. Pick what you're used to if the goal isn't to experiment.

silisili5• 5 years ago

If there's one thing I've learned on the topic in my life and career, it's that everything written should be written for the reader, not the writer. Perl, C, and C++ are very much for the writer. To some extent, Rust also.

Python and Go are good for the reader. These aren't exhaustive lists, just what I'm familiar with. Admittedly, Python is tricky because it looks simple(boring) at first glance, but lets one use a lot of magic.

My daughter is learning cursive and it just reminded me how much I blasted hate it. I can write it fine, reading it is a tossup. It's solely a shortcut for the writer, at the expense of reading. But anything of importance is read thousands or millions more times than it's written.

In programming especially, the easier to read the better, no matter how verbose and boring the language. I think we'll get there, when we all quit pretending we're too clever to write that way.

lmm3• 5 years ago

I find people make the mistake of thinking about how long it takes them to read 20 lines rather than how long it takes them to read x piece of functionality. (Of course it's much harder to compare the latter, but that's like the drunk searching for his keys under the streetlamp rather than where he dropped them). If there's a dense 200 lines of Haskell (or APL) takes you a week to understand, does that mean that Haskell is hard to read? Well, maybe, but if those 200 lines are replacing 20,000 lines of Go, then maybe not.

michaelcampbell2• 5 years ago

True, but everything is hard to read until you learn to read it; cursive included.

jefftk• 5 years ago

How much to optimize for the reader versus writer depends on context. In my daily work on a mature system I completely agree I should optimize for readers: the things I'm writing will likely last a long time, during which many people will work on them.

On the other hand, there are other contexts such as research or prototyping where it's much more important to get things out quickly; turn your ideas into code so you can see how they work.

pharmakom2• 5 years ago

Python is hard to read at scale in my view. There are no mechanisms for managing state effectively. Long procedures that mutate globals can be very difficult to follow.

tikhonj• 5 years ago

In my experience "boring" means "popular"—usually in the "you wouldn't get fired for choosing IBM" sense[1]. But somehow "use popular technologies even if they're bad" is not a convincing thesis!

[1]: Follow-up thought experiment: how many people should have been fired for choosing IBM?

otabdeveloper42• 5 years ago

C, C++, python and JavaScript

Coincidentally, also the languages actually used to make real-world software. (As opposed to self-congratulatory blog posts.)

If Rust or Ocaml ever get to the point when they're the tool for actually keeping the software ecosystems alive, they'll be terrifying too.

(It's not a problem with the languages; software is terrifying, that's a core property of software engineering and no amount of language abstraction will ever make the terror go away.)

P.S. I've been mentoring software developers for decades, and in my opinion the psychological ability to deal with the terror is the #1 predictor for success in the software industry.

Zababa6• 5 years ago

Could you elaborate a bit on the terror part please? That's the first time I've heard someone mention that, and it seems interesting.

skocznymroczny• 5 years ago

I think everyone has their own definition of boring. For example I wouldn't call C++ boring, but would call C boring. Java would also be a boring language.

For me a boring language is a language that has a single paradigm, and there's one way to implement most stuff. With C and Java, there is little room for making "fun" code, you just write lines and make it work. Java forces you into the OOP paradigm and every problem is just a few design patterns away. With C++ you can have a lot of fun with OOP, templates, compile-time magic, old C APIs, new C++ APIs, even if you solve the same problem, two codebases in C++ will look completely different.

vp89895• 5 years ago

I used to think this until I really took the time to dig into Rust. Rust has completely snapped me out of this depressing, "pragmatist" learned helplessness that people seem so keen to try to cram down everyone's throats these days.

ravenstine3• 5 years ago

Could you elaborate a bit? I'm curious precisely what you mean, though I can make some guesses.

vp89895• 5 years ago

Elaborate on what? Rust or the pragmatism stuff?

ashtonkem3• 5 years ago

I thought that too until I tried to recreate a web API I run at work in rust. Turns out that the language is far less important than having really great libraries. I’ll re-evaluate rust when things like resilience4j and micrometer exist for it.

vp89895• 5 years ago

"Turns out that the language is far less important than having really great libraries. I’ll re-evaluate rust when things like resilience4j and micrometer exist for it."

I agree. Ecosystem shapes how good a given language is right now but the language itself is what provides the long-term ceiling. One very real example is JavaScript. You can write all the JavaScript libraries you want and people certainly have ... but ultimately the language is what it is and many of its users still clamor for something better even after immense investment in the ecosystem.

MeinBlutIstBlau• 5 years ago

.NET is definitely not boring. I've seen some absurd things you can do in C# that still confuse me.

ghosss• 5 years ago

I think boring languages (apparently C, C++, and Java) are rated well enough. They are fine for software that is working okay, and is too expensive to rewrite in a language without the footgun that is “null”. But starting a new project in them is borderline malpractice for a lead engineer at this point. Please use a language that, if nothing else, statically prevents the “billion dollar mistake”.

Rust, replacing C/C++, or Java in some cases (not Android apps), and Kotlin, replacing Java, seem like winners. They are pretty boring in the end, and prevent programmers from making the mistakes that programmers consistently make. Swift also qualifies, if you happen to be writing an iOS app.

rightbyte• 5 years ago

If don't get where the hate for null comes from. It is a free runtime assertion that invalid objects are not used. The problem arises when invalid pointers are not null ...

kentm• 5 years ago

It's not so much that null is used but that every reference type is nullable in practice for languages that have it. Languages "without null" specifically mark certain variables as optional (same as nullable), so you're able to know that a given value is either always non-null or nullable (requires null check).

In terms of checks for null vs checks against an option type for data, there's some ergonomic improvements for languages with good option support, but it's mostly the same. The real benefit is that not everything is null, and if it is nullable then its explicitly called out.

MathMonkeyMan• 5 years ago

Boring languages have lots of loops and things that are required to have names.

voidhorse• 5 years ago

The more programming languages I use the less I care about this or that particular language and the more I think it comes down to the atomic level of good or bad features that are often available across different languages.

For example, I was writing some vimscript earlier today. Vimscript supports var-args in functions: bad idea. Dynamic type systems: generally a bad idea. Mixing declarative and imperative code: bad. Fancy comments/docstring systems (javadoc, python test): bad. Complicated type system features (e.g. dependent types): not necessarily bad but often unnecessary. Type casting: sometimes necessary but bad. Optional function arguments/arguments with default values: convenient but bad…

Basically any semantic element that increases the cognitive demand placed on the reader should be avoided. Circling back to varargs, they might be convenient when I’m writing a function initially, but they give readers no information, and it’s not uncommon at all that I have to go back and examine the precise details of how exactly I was using this or that vararg again.

Essentially, the more I program the more I think it’s best to use the simplest features possible and avoid anything fancy unless absolutely necessary, even when the fancy stuff is terser. This is part of what makes c, go, standard ml, scheme (even though I just knocked dynamic types) some of the best languages imo. Sure they are missing a lot of great writer-oriented features that programmers tend to drool over, but their absence is actually what makes these languages better.

avindroth• 5 years ago

Just to add some nuance: simplicity might be a boon for someone/company/industry working with multiple languages, but if you live in the, say, Java world, complexity may pay off for the native residents.

For instance, natural languages develop all sorts of intricacies that are inconvenient for the learners, but expressive for the native residents.

If the frequency of language usage is high, features of previously medium-level complexity become simpler and more “chunked”, due to how many times you have seen them (e.g. decorators in Python). So to Python residents, decorators are simple.

chillpenguin• 5 years ago

He mentions other things are more effective for leveling up (other things besides learning new languages). What are some of those things beyond "domain knowledge"?

Some things I can think of: databases, architecture, unix tools.

What else do people recommend doing to become a better programmer? I'll admit I've fallen for the "learn esoteric languages" trap for a large part of my journey as a programmer.

nwmcsween• 5 years ago

Boring languages don't have to eschew interesting concepts. The problem languages have is balancing abstraction without gaining state and losing performance. Ideally programming would consist of multiple small languages focused on specific abstractions (types, concurrency, functions, etc)

ksec• 5 years ago

When I talk to new programmers, they're often pretty influenced by this

They call it evangelist.

Zababa6• 5 years ago

A question I have is, why is online discussion about this topic so one-sided while the discussions I've had in real life are so oppositely one-sided. Of course, neither people who are loud on the internet nor people I personally know are representative samples of programmers, but I still find it interesting.

Programming languages are a kind of pyramid scheme. If you get more people into the community, you have more chances of using it at your day job, more libraries will be developed, more people will work on the language itself, more people will promote it and do cool stuff with it. Popularity brings even more popularity. And popularity is usually the most important feature of a programming language.

Edit: as mentionned by ashtonkem, the proper term would be "network effect" and not "pyramid scheme".

ashtonkem3• 5 years ago

The proper term for this is “network effect”. Pyramid schemes only make sense if you’re remunerated in some way based on the number of people you directly and indirectly bring to the language.

Zababa6• 5 years ago

Pyramid schemes only make sense if you’re remunerated in some way based on the number of people you directly and indirectly bring to the language.

But you are remunarated in a way. If your pet language become really popular, you don't have to choose between using it for less pay or not using it for more pay. That's either more pay or more happiness compared to the previous choice. There will also be more libraries, better tooling, better everything in general that will make you gain a lot of time.

Also, people that follow you will also be "trapped" in the language as they will have invested in it. If they want to make their investment better, one of the thing you can do it again, bring other people to the language.

Another thing is that if you're someone very important in a small language, and that language gets big, you become someone very important, period. Again, an incentive to bring people into it.

Boring Languages Are Underrated (2015)

Related Stories