Because It's Not Fun Enough | bytecode.news

ByteCode.News<br>Search posts🔍<br>RSS

historylanguagepsychologysoftware engineering

Andrew Oram wrote a two-part series for the Linux Professional Institute asking why programming languages rise and fall (parts one and two.) It says, roughly, that C, C++, and JavaScript are immortal (for now!), with Java a maybe; COBOL, FORTRAN, BASIC, and Perl lived respectable lives and got sent upstate to retire on a farm; Pascal, Objective-C, PL/I, Ada, and Tcl were false starts, with Ruby somewhere on the bubble. It's a good tour from a man who has been editing this industry's books forever, and near the end of it, Oram quotes Simon Peyton Jones, who observes that a language's adoption is "very weakly connected to its technical merits," and that the social and economic factors do the actual deciding.

That quote is the article, and it's a little surprising that it's buried so far into the content; maybe engineering for human nature makes it difficult to make that quote the leading thesis because we don't want to read that quite so bluntly, but it's true.

Language adoption is not solely technical - it's technical and human.

Everything in the two parts before that quote is evidence for the sentiment, assembled but never organized as evidence. The series sorts languages by outcome: immortal, respectable, and failed. The interesting sort is by cause of death, and the causes come out of a simple observation that Peyton Jones compresses and Oram circles: programming is done by people, and for people it is three things at once. It is a vocation, an art, and a job. A language serves someone practicing all three, and a language or tool that makes any of the three unnecessarily difficult will not survive past the moment it can be replaced.

A vocation is a calling the world happens to pay for: something someone would do anyway, paycheck or no paycheck. An art is something someone does out of love and (hopefully) skill, and a job is the daily work, the thing someone does so they can eat and watch TV and sleep under a roof and boring stuff like that.

Musicians live this triple identity every working day: the covers set is the job, the originals are the art, and the vocation is what puts an instrument in their hands every day, booked or not. Programmers live it too; we just don't say it out loud as often.

Sort the corpses that way and they separate cleanly.

Some languages failed as a job: standard Pascal shipped without a usable string type and Tcl couldn't carry programs past a certain weight, so the daily work was harder than it had to be.1

Some failed as an art: Ada and PL/I were chosen for programmers rather than by them, languages of mandate, and nobody has ever loved a mandate.

Some failed as a vocation: Perl's job market walked to Python and didn't come back2, and Haskell famously set out to avoid success at all costs, a goal it achieved3.

Different diseases, one pathology. In every case somebody made one of the three axes needlessly difficult, and the people the language depended on went where it was easier, or more fun, or more workable.

A language that makes life hard will not survive past the moment it can be replaced. That statement explains every anomaly on Oram's list. JavaScript fails as an art for a large share of the people writing it, and it survives anyway, because it remains the browser's main general-purpose language4. Objective-C was awkward as both art and job, and it thrived for fifteen years because it was the only door into the most lucrative developer ecosystem ever built; the moment Swift existed, it evaporated and now survives as a shadow, preserved in its descendant. COBOL survives because replacing it is too difficult and expensive - something some companies are noticing and trying to address. If they succeed, COBOL is likely gone: a language that works 100% of the time and is about 1% fun to program. Ada survives today where certification regimes made it nearly irreplaceable5. Its difficulty is a standing eviction notice. It gets served on the day an alternative shows up, and not one day sooner.

Which leaves C++ looming, difficult and immortal, apparently contradicting all of this. Rust too, difficult by design and rising. The thing is that there are two kinds of difficulty, and the series conflates them.

One kind of difficulty is the violin's: precise, demanding, and chosen because it is precise and demanding. People do codegolf in C++ for sport. People write essays about the day the borrow checker finally clicked, the way string players talk about the day vibrato stopped being a fight. Difficulty itself isn't fatal; difficulty without sufficient return is. C++ and Rust have that return, just as the violin does.

The other kind of difficulty is friction: Ada's compliance apparatus, standard Pascal's missing pieces6, COBOL's amazing and precise and demanding structural syntax that doesn't actually create program structure much at all. Nobody ever...