Because It's Not Fun Enough
This title could be clearer and more informative.Try out Clickbait Shieldfor free (5 uses left this month).
A response to Andrew Oram's two-part series on why programming languages rise and fall, arguing that Simon Peyton Jones's buried observation — that adoption is 'very weakly connected to technical merits' — is the real thesis. The author proposes that programming is simultaneously a vocation, an art, and a job, and that any language making one of those three axes unnecessarily difficult will be abandoned the moment a replacement exists. This framework explains apparent anomalies: JavaScript survives despite being poor as an art because it owns the browser; Objective-C thrived then vanished the moment Swift appeared; COBOL persists only because replacement costs are prohibitive. The author also distinguishes between productive difficulty (C++, Rust — chosen because the challenge has returns) and mere friction (Ada's compliance apparatus, Pascal's missing string type). The piece concludes that languages don't lose benchmark fights — they lose people, and the deciding question is ultimately whether using the language is fun.
Questions this post answers
Why do programming languages like COBOL and Ada survive despite being unpopular with developers?
COBOL and Ada survive because replacing them is prohibitively expensive or because certification and procurement mandates make them nearly irreplaceable — not because developers enjoy using them. COBOL works reliably but is about 1% fun to program; Ada is mandated for safety-critical environments. Both face an implicit eviction notice: the day a viable alternative appears, adoption collapses, as happened with Objective-C the moment Swift launched. Developers tracking which languages are gaining or losing ground find the signals early on daily.dev.
What is the difference between productive difficulty in a programming language versus harmful friction?
Productive difficulty is chosen because the challenge has sufficient return — like C++ or Rust, where mastering the hard parts unlocks real capability, and developers write passionately about breakthroughs like the borrow checker clicking. Harmful friction is difficulty that hits all three axes (vocation, art, job) for no payoff — like Ada's compliance paperwork or standard Pascal's missing string type. Both read as 'hard' in surveys, but only one survives. Teams deciding between Rust and safer but less expressive alternatives weigh exactly this trade-off on daily.dev.