Why programming languages succeed: vocation, art and job, not merit

The essay responds to a two-part series Andrew Oram wrote for the Linux Professional Institute asking why programming languages rise and fall. Oram's series sorts languages into three outcomes: immortal (C, C++, JavaScript, with Java a maybe), respectable retirees (COBOL, FORTRAN, BASIC, Perl), and false starts (Pascal, Objective-C, PL/I, Ada, Tcl, with Ruby on the bubble). Near the end, Oram quotes Simon Peyton Jones, who says a language's adoption is "very weakly connected to its technical merits," with social and economic factors doing the actual deciding. The author of the bytecode.news piece calls that quote the real thesis of Oram's series, buried rather than led with, and sets out to organize the evidence Oram assembled but never sorted by cause.

The author's framework: programming is a vocation, an art, and a job at once, the same way a working musician's covers set is the job, the originals are the art, and picking up the instrument at all, booked or not, is the vocation. A language serves someone doing all three, and if it makes any one of the three unnecessarily difficult, it will not survive past the moment something easier can replace it. Sorted by which axis failed, Oram's list separates cleanly. Some languages failed as a job: standard Pascal shipped without a usable string type, and Tcl could not carry programs past a certain size, so daily work was harder than it needed to be. Some failed as an art: Ada and PL/I were mandated for programmers rather than chosen by them, and nobody loves a mandate. Some failed as a vocation: Perl's job market moved to Python and did not come back, while Perl users spent two decades waiting for "Perl 6," which eventually became a separate language, Raku; Haskell, meanwhile, explicitly set out to avoid success at all costs and, per the author, achieved it.

The framework also explains the survivors Oram's list leaves as apparent exceptions. JavaScript fails as an art for many who write it but survives because it remains the browser's main general-purpose language. Objective-C was awkward as both art and job but thrived for fifteen years as the only route into the iOS and Mac developer ecosystem; once Swift existed, it evaporated and now survives only as a shadow inside its descendant. COBOL survives because replacing it is too difficult and expensive, which the author reads as a language that "works 100% of the time" and is "about 1% fun to program": if replacement gets easier, COBOL goes. Ada survives specifically where certification regimes make it nearly irreplaceable, a standing eviction notice served the day a substitute appears, not sooner.

C++ and Rust look like counterexamples, being difficult yet thriving, but the author argues the series conflates two different kinds of difficulty. One is the violin's: precise and demanding, chosen because it is precise and demanding, the kind people write essays about (the day the borrow checker clicked, the day vibrato stopped being a fight). The other is friction: Ada's compliance apparatus, standard Pascal's missing string type, COBOL's rigid syntax that does not actually create program structure. Nobody writes an essay about the day Ada's paperwork clicked. C++ and Ada both read as "hard" in a survey, but C++ survives because its hard parts sit on the rewarding axis and Ada's sit on the friction axis. Java gets a shorter treatment: it is not as difficult as C++ or Rust, does not need their kind of defense, and the author (who says he works in Java day to day and is biased) calls it currently immortal on both utility and fun, helped by recent packaging and feature improvements, though he admits he cannot say for how long.

The essay closes with a music analogy pushed past metaphor: a sampler can reproduce every note and nuance a violin makes, yet reproducing them takes more work than playing the violin, so getting the sound of a violin the easiest way still means playing one. The author says the same is true of playing his own guitar parts back through a machine: the result is fine, but the doing, which was the point, is gone. Code exists for the same reason a violin does: a program is a compact specification for behavior, and prose costs more than the notation built for the job. The essay's own conclusion: languages do not lose benchmark fights, they lose people, rising when they make the vocation, the art and the job lighter, and falling the day something else can carry the same weight, because the only question left at that point is whether it is still fun.

A set of footnotes adds detail the author treats as asides rather than counterarguments. Pascal's commercial life did not end in the classroom; it moved to Borland, where Turbo Pascal and then Delphi dominated PC development for over a decade. Turbo Pascal's author, Anders Hejlsberg, went on to build Delphi, then C#, then TypeScript, while Niklaus Wirth's own line ran through Oberon into Go by way of his student Robert Griesemer; the author reads this as Pascal being metabolized by influence rather than simply falling. On Perl, the author credits Larry Wall with letting the "Perl 6, any day now" goalposts move for two decades before Perl 6 became Raku, and jokes that most people would recognize Perl and Python in a show of hands but would need Raku explained to them. On Ada versus Rust, the author calls it conjecture that Rust is earning by preference the same certification-driven niche Ada earned by dictate, since neither Ada nor COBOL is facing mass replacement yet, though he says that uncertainty is itself the point of the argument.

Key facts

• The essay builds on Andrew Oram's two-part Linux Professional Institute series and a line Oram quotes from Simon Peyton Jones: language adoption is "very weakly connected to its technical merits."
• Its framework: a language survives only as long as it stays workable as a vocation, an art, and a job at once; failing any one axis kills it once a replacement exists.
• By this sort, Pascal and Tcl failed as a job, Ada and PL/I failed as an art (imposed by mandate), and Perl and Haskell failed as a vocation (Perl's job market moved to Python; Perl users waited two decades for "Perl 6," which became Raku).
• Objective-C thrived for fifteen years as the only route into iOS/Mac development, then evaporated once Swift existed; COBOL survives, per the author, because it "works 100% of the time" and is "about 1% fun to program," and replacing it is too costly.
• The essay distinguishes rewarding difficulty (C++, Rust) from pure friction (Ada, Pascal, COBOL) to explain why some hard languages thrive and others don't, closing with a music analogy: a sampler can reproduce a violin's every note, but playing it is still easier than driving the sampler, which is why code exists at all.

Why it matters

The piece pushes back on a habit common in engineering discussion: ranking languages by technical properties, benchmarks or feature checklists, as if adoption were a merit contest. Taking Peyton Jones's line seriously means treating language survival as a human and economic outcome, not a technical one, and gives a testable-feeling explanation for cases that pure-merit thinking cannot handle, like a language surviving despite being disliked by many of its daily users (JavaScript), or dying despite institutional backing (Ada, absent its certification niche).

Who it affects

Anyone who designs a language or a language ecosystem, maintains a legacy codebase in a language people no longer choose willingly (COBOL, Ada), or has to defend a language choice to a team; the essay gives that argument a vocabulary (vocation, art, job; rewarding difficulty versus friction) rather than a gut feeling.

How to use it

The essay offers a diagnostic, not a tool: for an existing language, ask which of the three axes (daily workability, the pleasure of writing it, the career path it opens) is under strain, and whether its difficulty, if any, sits on a rewarding axis or a pure-friction one. The author applies this to sort C++ and Rust (rewarding difficulty) against Ada and COBOL (friction) and to explain Objective-C's fifteen-year run and sudden replacement by Swift.

How solid is it

This is an opinion essay reacting to a secondhand series, not primary research: it carries no benchmark data, market-share figures, or citations beyond the single Peyton Jones line it quotes from Oram's original. Its per-language claims read as the author's own characterizations (COBOL's "100%"/"1% fun" framing, the Objective-C and Ada readings) rather than sourced measurements, and the author flags at least one of his own extensions, the Ada-versus-Rust parallel, as conjecture rather than established fact. The author also discloses personal bias on the one language he treats most gently, Java, saying he works in it daily.

Risks and caveats

The essay does not name its own author in the body text, gives no publication date for either Oram's series or this response, and supplies no calendar years for the duration figures it cites (Objective-C's "fifteen years," Perl's "two decades," Turbo Pascal and Delphi's "over a decade"). Read it as a framework for discussion, not as documented history: several of its central examples rest on the author's own judgment calls about what counts as "friction" versus "rewarding difficulty," a distinction the essay itself admits is not always clear-cut.

“very weakly connected to its technical merits”

— Simon Peyton Jones, quoted in Andrew Oram's series