The Average Developer Effect


Posted by Lelanthran
2021-06-01

“Programs must be written for people to read, and only incidentally for machines to execute.” – Harold Abelson, Structure and Interpretation of Computer Programs

New programming languages pop up almost as often as new Operating Systems, and for roughly the same reasons:- both those are an in-depth and foundational part of our everyday work1 and so we develop strong opinions on how they should work.

We look at all the friction we experience in $FOO (where $FOO is either a programming tool or an Operating System) and say to ourselves “There’s gotta be a better way”. And then many of us go off and try to make a better product that scratches all our itches and also, as a byproduct, eases all the friction we are experiencing with the current product.

Other people who share our particular strong opinions then start using that product and, because it is a strong opinion, they proselytise the benefits to everyone who will listen (and even to many who won’t).

And that’s how we get to new programming languages, in particular new ones that come out with features designed to ease particular pain-points.

Well that’s my theory anyway.

In practice, the new languages don’t merely add a pain-point easement, they add a plethora of new features. After all, if you’re creating a new language, why not chuck in some advanced features while you’re at it?

The struggle faced by new languages, and how it is real

If you were to look at the trajectory of a new language it will have insane growth in the first few years (because it’s starting from a small base of the first user. At that point even adding only a single user is a 100% growth).

Who are the typical programmers who try new and unproven languages that have no use in industry? How would you describe such a programmer, the early adopter of a new language? Does your description include the words “Smart” or “Intelligent” or “Motivated”? Does your description exclude the words “Practical”, “Risk-adverse” or “Predictable”?

So we have this new language, which sports features that are supposed to make programming better in some way … harder to make mistakes, more resistant to attacks, etc. And then the proponents of those languages tell us their experiences with it - “Never created a bug of type $BAR since I started using it” or “My programs now runs at twice the speed of light even when unoptimised or “Ported a 1000-line function from $OLD-LANGUAGE to $NEW-LANGUAGE and it’s only 2 lines in $NEW-LANGUAGE!”

We’ve all read the claims, many of them are no doubt true. But there’s a very important point that is missing when these claims are made - the proponent of the new language is never representative of the average programmer that this new language is designed for. The programmer who makes these claims of a new language is, almost by definition, the early adopter programmer.

The outlier, in other words.


For example, Haskell2 proponents’ claims that Haskell’s type system (probably understood by less than 5 in 100 working programmers) reduces bugs is a pointless claim: those 5 that do “get” Monads are probably in the upper percentiles as far as programmer ability goes. Even if the claim is correct, the average programmer doesn’t care because they simply aren’t going to learn Monads.

Another example, this time with Rust: almost all the developers that Rust targets (C++ programmers3) don’t care about compile-time lifetime/ownership checking. If they needed that they’d use C++ smart pointers and get 90% of that benefit, without need to learn a whole new language chock-full of syntactical differences between it and mainstream popular languages.

Enough examples, let’s move on - what happens as the language gathers momentum? It gets used by more programmers, of course! And then adoption slows down. Not because the market for that product is close to being saturated, but because the average developer looks at the complexity involved in using the language, then decides that switching to that language isn’t worth jeopardizing their delivery goals (or, later, their maintenance efforts).4

And then that language, that new language with all the advanced features, remains permanently in a state of “poised to take off”. It never does, of course; if one had, I’ve yet to hear about it. New languages which catch on use syntax stunningly similar to the rest of the mainstream languages.5


In a nutshell, that’s the average-developer effect at work: those programmers capable of learning the complexity of the new language are not the average developer. What the outliers like may not be what the other 99% like6. I’m not saying that we should discard what the early adopters are saying, I’m saying that we should keep in mind that their experience is via rose-tinted glasses.

Over time, once those few developers who are comfortable with the added complexity are all on-board the new language, adoption rates level off, stagnate or even fall (the rate of adoption, that is, not the percentage of use). At that point the $NEW-LANGUAGE has reached some sort of equilibrium in the market for programming languages. Barring some signficant changes (in the language and the competing langauges), that’s where it will stay, with maybe small movements over time as it and other languages get features bolted on.

The first time that I heard that Haskell was about to get really popular was in 2007! It gets repeated each year while the complexity of the language increases annually as well. We’ve been reading the same thing about Rust for about 5 years now - most loved language, but also least used compared to other languages that get mentioned as often in the software development press.

Year Rust Love Rust Popularity
2015 73.8% Too low to show up in results (< 7.8%)
2016 79.1% Too low to show up in results (< 6.5%)
2017 73.1% Too low to show up in results (< 1.8%)
2018 78.9% Too low to show up in results (< 4.2%)
2019 83.5% 3.2%
2020 86.1% 5.1%
Rust popularity

There’s some real growth there, but where’s the saturation point? Are we still at the early phase, where there are tons of C++ (and other native-code) programmers who are willing to switch to a new and alien-looking language or have we already converted all or most of the programmers willing to put up with the syntactical oddness?

Time will tell, after all, the 2021 Stack Overflow results are not yet out. Maybe this year will be the year in which Rust saw real gains on the incumbents, meaning that the pool of Rust-capable and Rust-willing developers out there was still larger than the pool of developers who had switched to Rust.


The implication of the average-developer effect is very depressing, though. New language features are introduced to the world via all these new languages which are seemingly destined to be relegated to niche uses. The existing languages evolve and gradually absorb these new features, thereby lessening the need for the average developer to actually switch to the new language.

Haskell introduced many features that were later adopted by existing languages, and yet Haskell usage is barely a rounding error. All evidence indicates that the current syntactical style of programming is here to stay; new languages merely serve as vehicles for expanding the feature-set of existing languages.

In 20 years from now, mainstream programming languages will pretty much look the same as current mainstream programming languages, because 20 years from now the average developer will pretty much have the same set of motivations and capabilities as the current average developer.


Posted by Lelanthran
2021-06-01

Footnotes


  1. I’m assuming that you, the reader, is a programmer of some sort; why else would you be reading my ramblings?↩︎

  2. I’m using Haskell and Rust here as the example languages. Haskell is the “old” new language - it’s been around for decades and only saw real growth in its first decade. Rust is the “new” new language - it’s only been around for eight years or so but I believe it’s trajectory is very similar to Haskell’s.↩︎

  3. If you were to make the claim that Rust is aimed at C developers, then we’d have to find a way to explain why all those C developers over the years who wanted a safer language never switched to C++, which has a shallower learning curve than Rust and, with smart pointers, gets you close to 90% of what Rust will give you.↩︎

  4. Not that programmers don’t like to learn new things, quite the opposite - programmers constantly spend their time on learning new things. However, there is a difference between learning a new framework that adds to your toolbox, and throwing the toolbox out completely in favour of a new and unproven toolbox.↩︎

  5. There might be something in this - the popular languages may all look similar because they have all independently discovered the most practical syntax programmers want to use. The languages that strayed too far from that syntactical norm have few users, comparatively. The languages that didn’t stray appear to be all converging on some ideal syntax.↩︎

  6. Confounding variables include the fact that programmers spend their days with multiple languages on multiple projects. It’s easier to context-switch between languages with similar syntax (C++, to Java, to C#). Throwing a brainfuck into the mix adds just a little bit of friction that would otherwise not be there. Most programmers need a very good reason to add friction to their work, as it impacts their performance indicators.↩︎