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.
Is like saying there’s more to a hammer than being a hammer.
Maybe you’re pretending the hammer is Thor’s Hammer and going on fantastic adventures slaying dragons.
I’m just building a table.
Edit: Damn -4 tell me how you really feel HN! Even my antisemitic posts are less downvoted, good for you guys
So it helps to choose a drill brand with the ecosystem you like, not just one that's a serviceable drill.
(Or you could argue that a language's ecosystem is part of the dang language. Which I agree with).
Why do you think people put up with Spring?
I consider npm to be part of "the interface of JavaScript" and to your point it's one of the strongest reasons beyond performance to use Node over some other dynamic language like Ruby or PHP.
Python earned its keep mainly because of its library ecosystem (again to your point) but also due to its simple, teachable syntax.
My point is that Python is not used because it's highly performant - it's basically the slowest language there is. But because people like the syntax and the library ecosystem (AKA the interface to the language)
If you are just building a table then hopefully you are not trying to do the whole thing with a keyhole saw.
Where one has a large library and runs on many platforms, and the other doesn't?
Where one behaves like PHP with respect to equality, and the other doesn't?
The closer metaphor is the handle. A saw handle may be ergonomic, that doesn't mean the quality of the blade is good, or even suitable for what you're trying to cut.
Best rebuttal here - yeah didn't think of that obvious one!
I had a larger point about language idealism / putting code on a pedestal vs getting the job done but yeah, this crowd can't handle that lmao
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.
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.
Perhaps the default choice is Common Lisp which itself is specified in an ANSI standard and has several competing implementations. Some are compiled, some are interpreted.
Arguably the best is SBCL, which has a mature compiler and garbage collection. If you lean on implementation-specific features you can produce extremely fast code that approaches the performance of C in some benchmarks, but idiomatic and portable lisp is slower in practice.
>Why should I use it instead of any other languages?
The killer feature used to be the REPL. You can write the application function by function, and test the functions, data structures, or classes you write in the REPL as you're actively building the app.
Nowadays with LLMs writing all the code, I honestly don't see much reason to reach for lisp. Agents don't require a REPL, and other languages have vastly superior library support.
The killer (hah!) feature is arguably its homoiconicity, allowing to modify the language easily within itself ("macros"). This has the obvious advantage that you can add missing features (usually) easily yourself; and exactly that causes headaches for those tasked with maintaining other people's code.
> Nowadays with LLMs writing all the code
Oh, you came all the way from the future and that's what you bring us?
and then use JUnit or TestNG in Java, or similar features in other languages. Which you can automatically run, including showing code coverage, both with a button in your IDE and as part of the CI/CD process when you commit.
If you've already thought out the whole program before you start writing it, that may not be as valuable. In my experience, software often isn't that way and the ease of exploration a REPL and long-running process provide are unmatched.
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'.
* 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.
Easiness is fun because it enables more messing around and learning. Not having to solve a problem is not fun, because problems are learning opportunities and are fun, unless they're just trivial obstructions in the way of the real problems of interest.
(And is why I know COBOL today, although I'm probably stronger on COBOL-77 than COBOL-85, when I STARTED COBOL after COBOL-85 was a thing.)
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.
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
In other words, object-orientation was the means, not the end.
Ruby allows (and to some extent encourages) unreasonable code.
It's not bad code (and in some cases extremely elegant), but it's code you can't reason about.
Being able to open any class (or object) and add new methods to it makes tracking how execution works extremely difficult.
The language allows for very undisciplined things to work - its great for the "scripting" and rapid prototyping - but unless you're going to throw it away the next day of having to maintain that code it starts weighing on the future speed of working.
Undisciplined code can be handled by making sure everyone on the team is disciplined in its use and documenting how things work... but that rarely reflects reality.
And so, you move to a language that enforces more discipline in how one uses it and is more reasonable in its execution.
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 )
Coming with a platform that is widely available or compatibility with an existing language on a platform was the killer feature for each.
Of course them being ISO(like) standards with competing implementations/tools was also important for C, C++ and Java as the cost to use and learn them was higher in the days before free open source languages, free tutorials and help forums became so wide spread.
But yeah official platform support and big company backing are a big part of why these languages have stuck around compared to others.
- 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).
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.
The iPhone came out after JS heavy pages came into existence, and might have accelerated the end of Flash and Java applets but the trend was already there.
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.
Feels like someone hasn't spent much time in the enterprise. Java is still doing pretty good in that space
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.
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?
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.
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 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.)
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.
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.
Compare with C++ which is widely hated, not because it's virtuosic - it really isn't - but because it's a bug-prone incoherent pile of archaeological standards and object bureaucracy, and most users only work with their own personally curated subset of it.
It's true some people like C++. It's widely used because it runs very, very fast, and trades that for slow compile times.
But some people also like jumping off mountains and trying not to hit the sides. I'm sure it's quite a rush on the way down. But not ideal as a daily commute.
There are a number of pragmatic reasons for this. Nobody is teaching ObjC anymore. Apple's documentation is now mostly Swift. Apple recommends Swift (and SwiftUI, despite the fact that many SwiftUI users have found it severely flawed). The job opportunities are mostly in Swift. I would say they're actually the same reasons people adopted ObjC back in the day. (Some other options were available, e.g., Carbon in pure C, Cocoa-Java.) Moreover, some newer Apple API are available only in Swift. Thus, Apple is pushing people into Swift whether they like it or not.
> There's nothing inherently wrong with either of us on those grounds.
Except that the thesis of your article depends on Swift being "more fun".
My belief is that Swift became popular among Apple developers for the same reason that Objective-C did before: Apple promoted the language. People jumped on Swift because they felt it was "the future". Some people were already claiming in 2014 that every line of code you write in Objective-C was "technical debt". Such claims turned out to be absurd, because old ObjC code still compiles and runs, while Swift 1.0 code does not.
Yes, it feels like legacy because Apple is making it into legacy. Do you not admit that Apple's actions have a profound effect on the relative adoption of the two languages among Apple developers?
I would note that Swift is, like Objective-C, almost nonexistent outside of the Apple ecosystem, even though cross-platform use is possible. Developers who are deliberately outside the Apple ecosystem are generally not interested in a programming language controlled by Apple.
Granted, Swift got a huge kick from the job department, but what you wrote said a lot more than that:
> A language that makes life hard will not survive past the moment it can be replaced.
> 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.
Apparently you're admitting now that "the moment" is a gross exaggeration. You're also admitting that the "art" aspect is controversial, a matter of personal opinions that vary. I'm not sure why you claimed that Objective-C was "awkward as... job" even before Swift existed?
I certainly don't see how using C++ would be less awkward on the job for developers than ObjC when the job was primarily calling ObjC system API.
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.
Bust: Python
If anything, the time of the ubiquitous JS might be over when anyone can generate native UI without electron.
JS ecosystem = capitalism, websites, payments
Python = math, language, theory