Because It's Not Fun Enough: why languages fail

I'd argue Rust is one of the most "unfun" languages in terms of syntax but it's offset by the crates ecosystem and cargo toolchain being easily the most pleasant within systems programming

No matter if C or C++ was more "fun", CMake is not and I think the the "fun" parts of coding are worse with Rust but the particularly unpleasant ones are relatively good. In that sense Rust's success might be due to it being more or a "pain pill" than a "vitamin"

Michael Hashimoto has made comments to the effect that Zig is attractive to him relative to Rust simply because it's more enjoyable to write but I think there's very few people for whom that could outweigh the lack of ecosystem

Even if you only consider the language itself, semantics, especially the type system, are more important than syntax.

Maybe not "fun", but people have preferences, not necessarily rational, in the choices they make. Programming languages, technologies, and even fonts.

Some languages are more enjoyable to use than others. I'm sure there are features/syntax/constructs in languages that you irrationally don't like.

Hmm. I find learning fun, no matter what the scope is - even Greek, which remains obscure to me. (Quick, ask me something about Greek! I'll nod wisely and stroke my chin in deep thought and then get distracted and wander elsewhere.) But you're not wrong: there's a fun discovery phase, then a "hey, does this actually work" phase, and then a "crap, I need to figure out how to MAKE it work" phase, all of which are decision points where one might choose to not bother.

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.

Also, since I tend to loop back: yes, "fun" is subjective, and your points about Objective C and Pascal were actually mentioned directly in the footnotes, including the "false start" nomenclature, which came from Oram, not me, and I mentioned COBOL's specific remaining survival directly as well. Comments are always appreciated, of course, but they're best when they actually address the article they're commenting on instead of inferences. I get that the article's not short - I don't enjoy 300 word things that lack nuance - but even so.

Perl is still in every Linux. I just checked one of my Oracle installs and there are 725 .pl files.

So it seems that is it still relevant.

I was programming computers in 1981. Pascal and COMAL were among my first structured languages. Your comment on the "naive opinion piece" is taken as it is offered, and I'm happy to offer you a full refund on your purchase price of the essay. :D

Note: am a head of engineering, and I've been writing code both as a vocation and a job for decades. I see it from a lot of sides; maybe not EVERY side, I'm not a machine (yet), but I don't think I have a singular myopic vision of ANY of it. YMMV.

What kind of workplaces you people have if you can code "for fun"?

I am tired of only ever being gauged by immediate usefulness. You hiring?

Also when you emphasize "exactly", you are not giving any actual reasons.

Hey, I actually made a point out of laughing about it even as I wrote it - see the footnotes. Haskell's dedication is actually quite remarkable and respectable, and it's not "against success" but against trading "correctness" for "success."

I'll be blunt about this:

It's probably also the reason statistically no one will be employed to work on a Haskell code base. Same for Lisp, F#, OCaml, etc. They're the hot rods of the software development world where everyone uses SUVs.

> 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.

> Sort the corpses that way and they separate cleanly

Just like when you get a bit of meat on the bone in a stew, and it all comes out as one piece - but it's just on the brink, and the slightest of touches with the fork is enough to make it separate cleanly, and it just slides off perfectly.

I love it when that happens. I really feel like the author does too. That's part of why I like reading things written by people. Shared enjoyment of a shared human experience.

I wouldn't call it stealing ideas, all languages build on ideas from older languages. language design is more akin to a academic discipline building on top of each other, languages have lineages like a family tree. Language users have usually no idea about the ancestry of the language they are using. Like Ruby borrowed heavily from Smalltalk, nobody is arguing Ruby stole from it.

But I agree the adoption is the key factor, more people using a language grows the ecosystem and it becomes self perpetuating from there. This is why I disagree with the article, I don't think python is a good language but I still wrote hundreds of thousands of lines in it over the last decade, not because it's fun but because of its strong ecosystem fitting the task at hand.

I am not especially a fan of Python, myself, but I think most languages would LOVE to have a "bust phase" like Python does. If that's failure, failure's not so bad. :D

Ridiculous.

If anything, the time of the ubiquitous JS might be over when anyone can generate native UI without electron.