There's more to a language than the syntax. The libraries, tools, and the ecosystem of developers, documentation, support, etc. are much more important. There are quite a few academic languages that are interesting to people that never really gain much traction because the people behind them just never commit to proper ecosystem building.

Switching languages is a big time commitment. Or at least it used to be. I find myself more open to that now that I can hit the ground running with AI coding tools in most languages. But still, it's a time investment to learn a language, its idioms, its way of doing things, all the tools, libraries, and frameworks, etc. It's not something you do an in afternoon. And certainly not mid project.

The languages that people gravitate to are the ones that look like they are safe, future proof bets. If you are going to spend all this energy learning one, you want to know it's a good investment. Successful languages have lots of users, decent tools, good libraries, etc. Or at least they look like there are serious people behind them. Many people make these bets early in their careers and then stick to them as well. I meet a fair share of people my age that are still sticking to Java. Because that's what they learned when they were in their twenties. I'm 51 now.

Rust is a good example of a language that's hard to learn but managed to get off the ground because of the solid people behind it. It wasn't just an academic exercise: Mozilla was trying to solve a real problem and they managed to get a nice community behind the language and it grew from there. This is not something that happens a lot. People create new languages all the time. But many stay very niche and the projects around them tend to go stale very quickly if they fail to attract a community of users.

Unfortunate how many languages with interesting stories were either glossed over or omitted entirely.

Clojure was an outright revolution against Java’s boring clumsiness, and many businesses are quietly making money with it today. Hickey even _explicitly_ comments on expertise (the OPs discussion about Rust and C++ being worth it) in the context of learning to play the violin.

Ruby declared itself as being all about “programmer happiness”, and while probably not as specifically a rebellion against Java, it attracted a ton of burnt out Java people who went on to found thousands of startups on Ruby. Ruby continues to be massive for web apps, Rails is still extremely popular compared to many alternatives.

Scala similarly to the previous examples was a Java-like with Haskell flavor that escaped an academic lab and accidentally took over the “big data” craze in the 2010s because they wrote Spark in it. If you were around then, Scala was truly hot at the time.

There are others of course but I found the examples in the OP a relatively surface level analysis of a space that has experienced an absolute explosion of diversity and novelty in the last 20 years.

The problem here is that "mechanical empathy" is for most neurotypical humans at odds with fun. It's hard to say that static typing is "fun" but at this point the benefits are so abundantly obvious that it's been shoehorned into Python via Pydantic and MyPy/Ty

I'd argue as well that "fun" for a lot of programmers seemingly entails over-abstracting, inventing complicated interfaces & following Clean Code dogma etc.

I think there's an inherent tension between what's fun and what is actually good software from a purely mechanical standpoint of performance and functionality

I'm calling bull on this. Learning languages, at certain points, is always tedious. Whether that language is a computer language, or something like Greek, there comes a moment where "trudging" begins. The reason a person "trudges" is that they have a goal in mind that makes the trudging something to endure until that goal is achieved. Fun comes from not having to solve the same problem sixty times, or having to sort through a million files by hand when a program can do it in 3 seconds.

I was hoping it would address Lisp.

Lisp is fun. The interactivity and instant turnaround of a Lisp REPL is still rarely matched in other languages. Common Lisp also solved a significant issue other languages didn't address well until much later: the ability to write high-level code that was fast on cheap hardware around the turn of the millennium.

Lisp didn't get popular around the turn of the millennium. Success stories like Naughty Dog, ITA, and Viaweb were rare, and the dominant languages seemed to be Java and various scripting languages starting with the letter P.

Yes to all that but still, my pet theory is that languages rise on one or two "killer features" that move the entire industry forward, and not the overall cuteness or lovability.

I can suggest a list of one killer feature per each popular language, i.e. things that these languages were the first to introduce and influence many successors:

C: extreme conciseness

C++: implicit destructors / RAII

Python: removed curly braces

Java: extreme portability

JavaScript: erm...

PHP: embedded in HTML by design

Rust: compile-time memory management

Swift: structured concurrency (pre-6 was probably just pure cuteness)

etc.

To add a few more exotic cases that affect things. Keep in mind that by default new languages fail. To succeed, many things have to all go right at once, and this implies that therefore there is not one single element that, if gotten right, means the language will therefore be successful (it's rather the opposite: If even one of the key factors is wrong, it'll probably fail).

* It's just a guesstimate, but one of those factors that caused java to be successful but-for (as in, if it hadn't had this, it wouldn't have been a success): It copies C style religiously anywhere it could get away with it. This caused some damage to the language that it has fixed in the past decade (such as the style and behaviour of `switch` being so bizarre - but it religiously follows exactly how it works in C!)

* Some languages end up failing partly due to community outlook. Scala is somewhat well known for having a core community that is highly aggressive and elitist, or to be a bit milder, to be 'less accepting of newbies with a limited understanding of programming concepts' than is optimal'. And in addition to that, they are in contrast to the java ecosystem ready to drop support for stuff quickly, meaning: Real life actual use of scala as a basis means you're either working with a hopelessly obsolete codebase or you're spending time refactoring it every other month pretty much. Scala's adoption is fading and never got anywhere near its hyped future.

* If a language is 'native to a platform' which I define as: "If the shepherds/owners of that platform were to write a basic app for their own platform, what language would they write it in? That's the 'native to that platform' language", then it tends to succeed even if it is not fun and not very well designed and even if transpilers exist. This is sufficient explanation for me for the success of javascript: It is the native-to-the-platform language if the biggest platform around.

These all fit within the thesis. They're all (last one is debatable) very human factors.

The stewardship and economics of the language can also be the issue. I started coding in the 80's and so web development for me evolved at the inception of the field. I will go to my grave insisting that Coldfusion was a better platform than PHP, but it was always commercial with a financial barrier to entry. PHP being free led to a glut of PHP developers, low-cost hosting, and an enormous ecosystem that ultimately redirected the course of the early web.

>That quote is the article, and it's a little surprising that it's buried so far into the content Is it really surprising in 2026? Today's online writing style is not primarily designed to communicate. It's designed to keep the reader 'engaged' for as long as possible. The reader's time is a resource to be extracted.

I'm absolutely not poking this author individually. It's the writing style of the net

I would say that out of the box functionality (in the language itself or stdlib) makes a difference these days too. Older languages aren’t really subject to this, but new languages can be hard to justify bothering with if they require you to reach for third party libraries (and all the security issues, drama, etc those can entail) for somewhat common/basic functionality.

An interesting example to look at is Java vs. Kotlin. While Kotlin is a bit easier and definetly more fun, it didn't manage to gain a big market share in the Java space so far. I guess that this is the case, because Java is good enough and seems to be the safer bet (at least for managers).

I tried to read this with an open mind but the premise of the article is so reductive I gave up quickly.

There’s a whole plethora of reasons a language might fall in or out of favour. From ecosystem lock in (eg Objective-C was mandatory for Apple development prior to swift and Visual Basic was ostensibly killed by Microsoft during the dot net upsell) to fragmentation in the community (eg Perl vs Raku). These don’t mean the languages aren’t “fun” nor productive.

Likewise, “fun” is such a subjective term that it’s utterly meaningless using it as any kind of yardstick. Esoteric languages are arguably the most “fun” but you don’t see companies running critical infrastructure on Brainfuck, Rockstar, nor lolcode.

And to say Pascal, Perl and Objective-C were false starts only demonstrates the author hasn’t used any computers prior to 2010. Perl was the de facto sysadmin language for literally decades. Pascal was the microcomputer language of choice before C++ took over (even to the extent that some 80s OSs are Pascal projects), Objective-C only disappeared because Apple introduced Swift. And the authors comment about COBOL being retired is untrue for anyone who’s worked on critical banking software.

I honestly think AI slop would have more value than this naive opinion piece.

> C, C++, and JavaScript are immortal (for now!), with Java a maybe

Feels like someone hasn't spent much time in the enterprise. Java is still doing pretty good in that space

For quite a period up to LLMs, coders had high amounts of social power and gleefully asserted it by e.g. flouting dress codes and asserting their preference in tool choices. This is why we still see articles like this arguing everything from a point of view akin to that of a hobbyist, rather than articles by heads of engineering establishing that this kind of screwdriver is optimal for industrial automobile assembly.

I'm retired now but it never occurred to me the vocational languages I enjoyed most were all respectable or false starts (or obscure): FORTRAN, Pascal, Icon, Ada, Tcl.

And in hindsight, I only grudgingly accepted the immortals, although I recognized at the time they would be widely adopted: C, C++, Java, Javascript, and Python.

Is awk still respectable? Is it even a programming language?

Heh, the article is kind of negative about Haskell's "success", but fun is exactly the reason why I still prefer Haskell over all other languages.

> For the person who only wants the notes, the sampler wins the job outright, completely. It will never play the wrong thing or at the wrong moment. For the person playing, it fails, because driving it costs more than playing, and it never touches the art at all.

This entire essay could be about AI adoption as well. Some programmers love to program, and while AI is great at producing the code, it doesn’t really viscerally appeal if one loves coding itself.

It's ridiculous to call Objective-C "a false start".

1) Objective-C is 40 years old.

2) Objective-C was used to create NeXTSTEP and by extension Mac OS X and iOS.

3) Objective-C is no more "awkward" than any other programming language. I actually prefer its verbosity to Swift's terseness.

4) Although Swift did eventually become more popular, the claim about Objective-C that "the moment Swift existed, it evaporated" is not only false but a gross exaggeration.

> Different diseases, one pathology.

I've also researched languages and written a similar piece[1]. Most successful languages had adoption momentum outside of the language itself. Conversely, there are many interesting failures—languages that were technically fascinating but ended up having their ideas stolen by later successful languages. A language isn't like a paper; it doesn't compete solely on the quality of its ideas [1]https://www.makonea.com/en-US/blog/programming-languages-are...

Boom: JavaScript

Bust: Python

Personally I think expressivity and type system power are what make a language "fun". If languages were video games, the Lisp family and Lean4 feel much more like an open-world game with many ways to play it like Factorio or Minecraft.

At the other end, Go would perhaps be the equivalent of an on-rails shooter.

And it honestly makes me disagree with the thesis here because "boring" unexpressive languages have arguably outperformed in terms of adoption for loadbearing software

Hah! SO MANY LANGUAGES got skipped, even from my own CV. I wanted to address Louis/II, for goodness' sake, but it's a CODASYL tool, and not a lot of people remember CODASYL from experience. (Nor should they: I liked it, but... nah, RDMS won for good reasons.)

Lisp is certainly fun, and it lives today and is influential today in multiple environments; I have a Clojure app I work on for my own amusement. And it does have commercial appeal, but it's limited; the three axis thing applies.

I often hear about lisp but never actually figured out what tooling you need Is it interpreted or compiled language? Why should I use it instead of any other languages?

I really enjoy writing lisp but the ecosystem of libraries is a barren wasteland.

Try to find a TLS library for Common Lisp that doesn't rely on openssl, for example. Last time I looked the most mature library was marked 'experimental'.

C is not "extremely concise". Lisp, and especially APL both predate C and are more concise. To me, the "killer feature" of C is UNIX, we can't really separate them, C won because UNIX won and vice versa. Other than that it is reasonably concise, reasonably portable and reasonably low level. The language itself doesn't have any "killer feature".

For Python, I think its killer feature, related to the removal of curly braces is that it is a dynamic language (like Perl) that forces you to write somewhat readable code. You have no choice but to indent correctly, and there is a strong "pythonic" ideal way of coding, the complete opposite of Perl's "more than one way to do it".

JavaScript killer feature is obviously its integration in browsers but it is also well designed for this task, with pretty good support for asynchronous programming.

Still, I don't think any of these languages were successful for their "killer features", more because of a combinations of many things. In many cases, they weren't even the first. For example, there are several langages that use indentation as syntax that predate Python. ( https://en.wikipedia.org/wiki/Off-side_rule )

C++ succeeded because it was Object Oriented, people didn't start talking about RAII as C++ killer feature until years later

python succeeded because it wasn't Perl's TMTOWTDI, everyone expected ruby to overtake python, but .. for some reason that never happened

swift succeeded because apple pushed it to replace objective c, that if you consider swift succeeded

anyway, i agree with your premise, languages need one key strategic advantage feature to succeed, but you just got it wrong on few of them .. and if i am wrong too, then the premise is weak, if we are not sure what the killer feature is, we then have no idea why the language succeeded

C came with an OS. C++ came with compatibility with C and at the peak or near peak of OO hype. Javascript came with the browser making it probably the most widely available language platform. Swift came with Objective-C compatibility, an OS, and money (iOS app store customers spend more on apps than their Android counterparts).

Coming with a platform that is widely available or compatibility with an existing language on a platform was the killer feature for each.

I like that theory, if I was going to counter it though, I'd say that I'm not sure those features match what language users talk about. For instance:

- C: Users often praise the simplicity of the language

- C++: Users often praise (not always praise?) the large feature set for a low level language

- Python: Folks talk a lot about "batteries included". Although in all honesty, I think having good interaction with other low-level languages is Python's secret feature.

- Java: Really leans in hard to object oriented programming

- JavaScript: Haha, you have to use it!

Not sure I'm really disagreeing with you though, but I think Java promoted its portability much more than it's ever been used (obviously there are cases like Spark which uses the JVM portability).

I believe JavaScript's was running in the web where Java could not (iPhones) or was considered too heavyweight (no startup).

Then it became the true extremely portable language, because developers wanted a single language to write webapps in, and it was easier to get JavaScript running on their server than a new language running on every browser.

JS despite its (many) faults still allowed a fairly functional style way before that was mainstream. Java and C++ only got lambdas decades later.

Except for PHP I don't think that's a very fitting list. C for example, is not really a concise language, not even for its time - APL is much more concise. C is rather verbose.

Likewise, Python is not the first language without braces - and it debuted before braces became the industry standard. I guess ISWIM or ABC are the first to have syntactic whitespace.

Really, you will always find an earlier example for a "killer feature", at least in an academic context - in the case of your list, usually in the 1960s, in the 1970s at the latest.

> AI is great at producing the code

It's not. The latest-and-greatest models on $200/mo subscriptions routinely produce bloated code full of boilerplate. They are incapable of producing elegant, concise, readable, correct-by-design code - they literally can't do it, even with the smallest samples, and it gets much worse as the scale of the implementation increases. You can't will the capability into them through prompts. You probably could do so with fine-tuning or other techniques, but I suspect that would just make the variance higher - and the average code quality would be much lower than it already is.

The code generated by LLMs is passable, but never truly good. The same is true for LLM-generated designs and architectures, just even more so. They are trained on all the code out there, and the percentage of really good code is so vanishingly small that it's incredibly hard to replicate even for humans after a lifetime of learning. LLMs would need to reach a next level of capability to consistently recognize good code. Generating it consistently is out of the question for at least the next few generations of the AI.

Not all code has to, or needs to, be good. LLM-generated code is useful and helpful. It's an incredible time-saver for one-off scripts, and you can make an LLM implement and maintain parts of the program you need, but don't care to make good at the moment. LLMs are very efficient (if we ignore externalities) and easy-to-use code generators, which is huge in itself. However, they are not great or even good at generating code.

Last weekend, there was a post showcasing a Rust library with utility functions for writing parsers. It featured a simple line-by-line INI file parser. I decided to rewrite it in Python with PyParsing, a library I happen to know well. GPT-5.6-Sol High wrote the grammar that worked. It was tragically bloated, poorly factored, and multiple grammar problems were masked by parse actions. It worked, but it was decidedly bad code. I then rewrote the grammar by hand, getting it down to 1/3 of the length, eliminating all parse actions, and improving error messages in the process. I then spent 2 hours trying to convince the model to perform the same refactorings I did, but had to give up: no matter what I tried, the model couldn't get all the needed changes to coexist at the same time. When it got the terseness right, it inevitably ruined error handling. When it got the grammar right, it ruined the factoring. And so on.

Later on, I decided to make the model rewrite the PyParsing grammar in Smalltalk's PetitParser - a pretty close match in terms of capabilities. I gave the model my version of the grammar. I told it to translate that Python code. It still butchered more than half of it, doing "optimizations" (the model's words) that replaced a cached production with a literal + 3 message sends in 8 places in the (trivial!) grammar. I explained what I value in the original code, why those are important features to keep, and tried again. It still couldn't give me an idiomatic Smalltalk translation, though it did get significantly closer. I concluded that the model has a very limited understanding of how concepts I wanted can manifest in actual code and called it a day.

To give you an idea of the scale: excluding blank lines and imports, the grammar is exactly 10 lines of Python...

So no - LLMs are not good at generating code. They are just fast and convenient, and again - that's huge. But it's nowhere near a level where it can be steered to produce good code - much less being able to generate good code by default.

(I realize this post is a bit off topic and it's just an anecdote - but I've experienced this daily for the past half a year; I'm not basing my opinion on just that last attempt.)

OP here. Yeah, you're not wrong. A lot of what IS driving AI code is that the writing code part isn't the intriguing aspect: it's designing, and the code generation is the grunt work that makes the design happen. And then you find out that most humans aren't that great at design: most programmers handwave their way through specifications, and thus the AIs do what they're told, and generate utter dreck, a lot like some of the "melody generators" do - they get handed very artificial constraints about what "good melodies" sound like, so they all sound very ordinary, because they STILL lack soul and replace inspiration with algorithm.

OP here: Fair. Yet I'd say that it's relatively rare (while being completely absent in my experience) that anyone would choose ObjC today - and the article even mentions Pascal as a stronger example of the model you use with ObjC. ObjC survives today, as does Pascal, but its strongest impact is through influence, just as with Pascal.

And languages being awkward is entirely a personal opinion, agreed. You might think in ObjC. I do not. There's nothing inherently wrong with either of us on those grounds.