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.
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
Agreed, rust is SUPER not fun IMHO but I use it a lot via FFI for things I wouldn't do in Elixir which I prefer to write/read. The broad array of well built tools on cargo is just so hard to compete with, and cargo as a tool beats any language tooling for any language with similar breadth. The JVM has every tool imaginable but I'd rather built it myself than tangle with JVM tooling.
Many people don't really understand the languages they learn until well after they are done mastering them. And some never really pick the deep detail there is to semantics and type theory.
If it is done right, the language might feel nice to use or elegant but users might not articulate why that is. That can be a key selling point. And of course there are a lot of languages where the type system was a bit of an afterthought that got popular anyway. Javascript and other dynamically typed languages comes to mind. Rust kind of sits on the other end of the spectrum. And it has a deserved reputation for being a bit hard to learn because of it.
Arguable. Both are really important. We all know the most run-down-looking restaurants have the best food, but we still go to the ones that look clean and tidy anyway.
I think the more appropriate analogy is there's more to a drill than the drill. When you buy a Milwaukee drill, because it shares a battery with other Milwaukee parts, it's easier to buy more Milwaukee tools.
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).
I still attribute a rich OOTB standard library for Go’s success. You have an OOTB production capable web HTTP server baked into the standard library since practically day 1?
They were made roughly around the same time to be fair, but Go's standard library was richer at the time I thought? Even so, JavaScript hate it or love it (I both hate and love it) is massive by virtue of being the primary scripting language for front-end web. I am fully aware of its backend capabilities, but Go gave us: C-like syntax, natively compiled, and a rich OOTB standard library that Google uses in production. Even YouTube adopted Go early on and made Vitess which was a "middle-man" for MySQL which helped YouTube with their back-end starting in 2010, it would help with query routing and sharding, connection pooling, query safety and even optimizing queries before they got to MySQL, as well as row-level caching.
Honestly I'm not trying to downplay Node, I respect Node for what it was and is, but Go punched above its weight early on too.
I think the industry was starved for a back-end language that was simple, compiled natively (removing a lot of environmental setup overhead) and was production ready out of the box.
Node.js came way before Go. If you fact-check with AI, it will say "Go was invented in 2009" but anyone who has been around knows it's more like ~2013.
Node.js was 90% of the inspiration for Go to exist in the first place.
Swift also would have never came about if it wasn't for people doing iOS way better in JavaScript.
Technically 2007, but Go 1.0 was in 2009 when the Windows compiler was finally released, Go from 2007 till 2009 was Linux / Unix first. I don't recall when Mac came, but I would not be surprised if very quickly given that GCC worked just fine on Mac at the time.
The Go community made Go work on Windows leading up to 2009, the core maintainers of Go did not make the Windows build themselves, they didn't care about Windows being a target.
2013 is when the rest of the world was starting to catch on to Go I suppose, Docker came out in 2013, but I distinctly remember learning Go on Windows in 2009 and building web apps, without any third party packages.
Libraries and frameworks and package management absolutely matter. They're not some abstract thing, they could be the difference between something being done in 6 months or in 2 years.
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)
Comparing a languages syntax to a saw blade is a bad analogy. A saw is a complete tool. Syntax is more like the teeth on the saw blade. The quality of the saw is not just about the teeth. It's also about the size and spacing of those teeth, the strength of the blade those teeth are on, the shape of the saw blade itself, the hardness of the metal, as well as the shape of the handle.
If you are just building a table then hopefully you are not trying to do the whole thing with a keyhole saw.
So 2 languages are the same if they have the same syntax but 1 is interpreted, and not safe, whereas the other is compiled and safe?
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.
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.
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.
It totally depends whether you're still experimenting and learning or not, which is totally circumstantial. Sometimes I slog through things at the start, on the promise that they will start to be fun once I see the point.
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.
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.
Totally fair, but as I mentioned elsewhere, I left a lot of languages out in my consideration even when they're on my CV. Heck, I work in Java in my day job - I'm taking time away from it to write this comment - and realized after I'd finished my third draft that I didn't mention it at all. And I DO Clojure, have done Ruby, have done Scala (and will never do so again if I have any choice in the matter).
I could have gone into each language as a sort of postmortem - even for the ones that aren't dead right now - but for every one of them there'd be a host of people saying "wait, you're wrong" and they'd be right, and maybe I would be in that host saying I was wrong at the same time. (Again, see the footnotes: it's right there!)
But the piece isn't abotu a postmortem analysis of whether a language is fun or not - what I enjoy isn't going to be what you enjoy, nor should it be, and I don't care what you use, as long as you use it well and for the benefit of mankind.
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.
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?
"Lisp" refers to several different languages in the same family, which contributes to the confusion.
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?
I never said I liked the future, but it is what it is.
If you're building products without LLMs today you're going to get outcompeted by people who do, and can iterate faster. I have written a fair bit of lisp and when it isn't refusing to fix security bugs because openai are cowards, 5.6-Sol can do in hours what would take me days.
> You can write the application function by function ...
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.
Unit testing doesn't provide the level of interactivity a REPL does. A REPL lets you see the output of parts of an unfinished function based on the running program's state.
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.
yes and no. You are correct the REPL provides more interactivity. However the downside is you can break something that used to work while make something else work.
There is no reason you can have a REPL and unit tests in the same. Every change results in running all the tests. (of course most changes are syntax error - just "if foo()" is 7 syntax errors. ) I've seen various attempts of this over the years, but quickly your code becomes more complex than the computer can run while you type and you fall back to running most of the tests after in some way.
I think we're largely in agreement here. Unit tests and REPLs serve different purposes and are poor substitutes for each other; red_admiral was arguing that unit tests obviate the need for REPLs.
>I've seen various attempts of this over the years, but quickly your code becomes more complex than the computer can run while you type and you fall back to running most of the tests after in some way.
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'.
This is the double edged sword of particularly extensible customizable languages is that they invariably won't produce a robust ecosystem of packages that can compose with each other in the manner of pip/npm/crates
>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
Yeah, and I despise it. :D I purposefully expose the lede in my own articles early and often and as up front as I can make it - the editorial reviews keep saying "you should optimize for the clix, maing!" and ... no. If someone doesn't want to read the crap I come up with, I want them to know they don't want to read it right out of the gate, personally.
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)
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
Initially, it provided a thin object-oriented abstraction over C. This solved many problems scaling large C projects. It set baseline expectations for languages that came later. Being a "thin object-oriented abstraction over C" has significant limits. By the 2000s, it was clear that C++ couldn't scale complexity in the way we needed it to. It was slowly dying.
C++ reinvented itself as a functional metaprogramming language starting with C++11, providing an even higher level of abstraction. Many deficiencies in the older language and systems languages generally were addressed. This was a huge success, creating a large resurgence in adoption and setting new expectations for what a systems language should be capable of. C++20 looks like a completely different (and much better) language than C++98.
I view C -> legacy C++ -> modern C++ as the evolution of a single language. Each was wildly successful on its own up to some level of complexity. Every time it runs into a practical limitations on scaling complexity, it adds a new layer of abstraction. As much as people complain about it, this strategy has clearly been successful.
I don't think C++ succeeded because it was object-oriented. I think C++ was object-oriented because classes were an abstraction that could layer on top of C with fairly low overhead, giving it more expressive power without much mandatory cost to size or speed.
In other words, object-orientation was the means, not the end.
> python succeeded because it wasn't Perl's TMTOWTDI, everyone expected ruby to overtake python, but .. for some reason that never happened
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.
To have a theory of success, you have to also be able to explain failure. Why did object-oriented C (aka C++) take off but object-oriented Pascal (aka Delphi) not, despite the fact that Pascal was as prevalent as C in those days? Why was Python able to overturn Perl's dominance in the scripting space, but Ruby was unable to do so? Why did Ada and Smalltalk never achieve significant dominance?
A lot of success does come down to being in the right place at the right time. JS was successful because it was the only available scripting language for the web (although MS pushed VBScript for a bit) when there was a concerted effort to kill off the Java and Flash plugins. C was successful because it was tied to the Unix OS, which happened to overtake other OSes for a variety of reasons.
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.
Yeah, this is a more honest assessment than the others I've read here.
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.
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.
Javascript didn't need a plugin, unlike Java, and could directly alter the page contents. One of the first heavy uses was Google Maps, interactive JS-based applications took off at that point. Then with an army of web developers (meaning in browser), Node took off when it handed them a way to work on the backend in the same language.
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.
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).
Let's be real here. JavaScript didn't take off because it was functional in the functional programming sense. It took off because it was built in and procedural. You didn't need to muck around with objects if you were a total noob. You'd just write your functions and call them with strings as parameters.
Javascript took off because it was your only option for a lot of things. Flash and Java tried, but both were always hit and miss as to who could use it. Everybody had javascript in their browser so you had no choice if you were to reach them but meet them where they were.
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.
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.
Programming languages are under a Darwinism-like pressure of programmer's attention. They have to fit a niche, and the ones that fit the niche best, survive. What another commentator calls killed features is, to me, a way to fit a niche.
Sometimes that niche is fun, like Python. Javascript's niche is that it's literally the only option. I suspect some languages (Java) fill a niche because they've been there for so long there's no oxygen for anything else to have a chance.
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
All languages are fun, but the most fun programming languages are ACPUL, Lisp and fun esoteric languages like Brainfuck. Enterprise made programming less fun while the most popular languages are popular mainly because huge budgets are allocated not only to promote them across every platform, but also to pay salaries.
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.
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?
All of them are respectable. I've done most of those - Icon's new for me, and I don't think I've ever written anything in Ada either although I've come unfortunately close thanks to industrial requirements. I escaped!
And yes, awk is a programming language. And respectable. I tend not to use it much any more, but that's because there are other things that feel easier than remembering the syntax. C'est la vie.
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).
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.
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.
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."
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.
> 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 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.)
Yeah, definitely on point. I use AI for code generation, but I ride herd on it quite a lot and I limit scope viciously and with hard rules about what the models are even allowed to generate. It's worked out pretty well, but it's hardly the "oh send a question get a full system back" that people try to pretend it is.
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.
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.
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.
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
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.
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.
ObjC "failed" because it was locked inside the Apple ecosystem, and Apple made no serious effort to change that. Ref counting aside, I thought it was a wonderful fun language. But it was always platform specific in a way that other languages aren't.
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.
> Yet I'd say that it's relatively rare (while being completely absent in my experience) that anyone would choose ObjC today
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.
Well, the problem here is in your own words: you say `My belief is` - and so it is. I cannot and would never presume to tell you what you believe. Yet I believe otherwise. Swift won on multiple axes; ObjC is still around but feels like legacy to me, much like Pascal does: influential (heck, I use ObjC terminology when describing OO concepts, over Smalltalk!) but not, like, a living language at this point even though its death might be, um, a lot more rumor than fact.
> ObjC is still around but feels like legacy to me
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.
And yes, you're absolutely right. Apple is making a choice here, and they absolutely have impact on what the developers "get to use" - much as .Net succeeds largely to vendor choices on Windows, too. And developers get to suck it up! That's the three axis thing again: vocation, art, job. Swift and .Net both got a huge kick from the "job" department. That's how it goes.
> That's the three axis thing again: vocation, art, job. Swift and .Net both got a huge kick from the "job" department.
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 wrote that it was awkward because IMO it was. That is indeed "my opinion" - I found the language it used to express concepts far more useful than the language itself, and found myself writing C++ far more often than ever wanting to write ObjC.
> 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'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...
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
If you knew anything about payment systems, you'd know you get a nonce or receiptID and it is a front-end only thing. You don't do the backend banking yourself.
Maybe your backend sends an email, or saves the receipt, but that's peripheral.
The entire Payments flow is front-end capture, then the service doing all the actual backend payment part. It's a black box from your end and you can decide to do it entirely front-end if you wanted. There's no way around it.
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.
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
Agreed, rust is SUPER not fun IMHO but I use it a lot via FFI for things I wouldn't do in Elixir which I prefer to write/read. The broad array of well built tools on cargo is just so hard to compete with, and cargo as a tool beats any language tooling for any language with similar breadth. The JVM has every tool imaginable but I'd rather built it myself than tangle with JVM tooling.
Even if you only consider the language itself, semantics, especially the type system, are more important than syntax.
Many people don't really understand the languages they learn until well after they are done mastering them. And some never really pick the deep detail there is to semantics and type theory.
If it is done right, the language might feel nice to use or elegant but users might not articulate why that is. That can be a key selling point. And of course there are a lot of languages where the type system was a bit of an afterthought that got popular anyway. Javascript and other dynamically typed languages comes to mind. Rust kind of sits on the other end of the spectrum. And it has a deserved reputation for being a bit hard to learn because of it.
Arguable. Both are really important. We all know the most run-down-looking restaurants have the best food, but we still go to the ones that look clean and tidy anyway.
[flagged]
I think the more appropriate analogy is there's more to a drill than the drill. When you buy a Milwaukee drill, because it shares a battery with other Milwaukee parts, it's easier to buy more Milwaukee tools.
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).
I still attribute a rich OOTB standard library for Go’s success. You have an OOTB production capable web HTTP server baked into the standard library since practically day 1?
Have you never heard of Node.js where they got the idea from
They were made roughly around the same time to be fair, but Go's standard library was richer at the time I thought? Even so, JavaScript hate it or love it (I both hate and love it) is massive by virtue of being the primary scripting language for front-end web. I am fully aware of its backend capabilities, but Go gave us: C-like syntax, natively compiled, and a rich OOTB standard library that Google uses in production. Even YouTube adopted Go early on and made Vitess which was a "middle-man" for MySQL which helped YouTube with their back-end starting in 2010, it would help with query routing and sharding, connection pooling, query safety and even optimizing queries before they got to MySQL, as well as row-level caching.
Honestly I'm not trying to downplay Node, I respect Node for what it was and is, but Go punched above its weight early on too.
I think the industry was starved for a back-end language that was simple, compiled natively (removing a lot of environmental setup overhead) and was production ready out of the box.
Node.js came way before Go. If you fact-check with AI, it will say "Go was invented in 2009" but anyone who has been around knows it's more like ~2013.
Node.js was 90% of the inspiration for Go to exist in the first place.
Swift also would have never came about if it wasn't for people doing iOS way better in JavaScript.
SwiftUI is basically React conceptually
Technically 2007, but Go 1.0 was in 2009 when the Windows compiler was finally released, Go from 2007 till 2009 was Linux / Unix first. I don't recall when Mac came, but I would not be surprised if very quickly given that GCC worked just fine on Mac at the time.
The Go community made Go work on Windows leading up to 2009, the core maintainers of Go did not make the Windows build themselves, they didn't care about Windows being a target.
2013 is when the rest of the world was starting to catch on to Go I suppose, Docker came out in 2013, but I distinctly remember learning Go on Windows in 2009 and building web apps, without any third party packages.
Fair points, but those preferences seem more grounded in reality than the abstract reasons people say they love a language beyond its interface
Libraries and frameworks and package management absolutely matter. They're not some abstract thing, they could be the difference between something being done in 6 months or in 2 years.
Why do you think people put up with Spring?
1000% that's why I said "Fair points"
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)
Comparing a languages syntax to a saw blade is a bad analogy. A saw is a complete tool. Syntax is more like the teeth on the saw blade. The quality of the saw is not just about the teeth. It's also about the size and spacing of those teeth, the strength of the blade those teeth are on, the shape of the saw blade itself, the hardness of the metal, as well as the shape of the handle.
If you are just building a table then hopefully you are not trying to do the whole thing with a keyhole saw.
So 2 languages are the same if they have the same syntax but 1 is interpreted, and not safe, whereas the other is compiled and safe?
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.
> compiled vs interpreted
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
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.
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.
It totally depends whether you're still experimenting and learning or not, which is totally circumstantial. Sometimes I slog through things at the start, on the promise that they will start to be fun once I see the point.
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.
Indeed! That's how it works, pretty much every time, unless language choice is dictated from above, which ALSO happens.
(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.)
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.
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.
Totally fair, but as I mentioned elsewhere, I left a lot of languages out in my consideration even when they're on my CV. Heck, I work in Java in my day job - I'm taking time away from it to write this comment - and realized after I'd finished my third draft that I didn't mention it at all. And I DO Clojure, have done Ruby, have done Scala (and will never do so again if I have any choice in the matter).
I could have gone into each language as a sort of postmortem - even for the ones that aren't dead right now - but for every one of them there'd be a host of people saying "wait, you're wrong" and they'd be right, and maybe I would be in that host saying I was wrong at the same time. (Again, see the footnotes: it's right there!)
But the piece isn't abotu a postmortem analysis of whether a language is fun or not - what I enjoy isn't going to be what you enjoy, nor should it be, and I don't care what you use, as long as you use it well and for the benefit of mankind.
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.
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?
"Lisp" refers to several different languages in the same family, which contributes to the confusion.
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 feature used to be the REPL.
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?
I never said I liked the future, but it is what it is.
If you're building products without LLMs today you're going to get outcompeted by people who do, and can iterate faster. I have written a fair bit of lisp and when it isn't refusing to fix security bugs because openai are cowards, 5.6-Sol can do in hours what would take me days.
> You can write the application function by function ...
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.
Unit testing doesn't provide the level of interactivity a REPL does. A REPL lets you see the output of parts of an unfinished function based on the running program's state.
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.
yes and no. You are correct the REPL provides more interactivity. However the downside is you can break something that used to work while make something else work.
There is no reason you can have a REPL and unit tests in the same. Every change results in running all the tests. (of course most changes are syntax error - just "if foo()" is 7 syntax errors. ) I've seen various attempts of this over the years, but quickly your code becomes more complex than the computer can run while you type and you fall back to running most of the tests after in some way.
I think we're largely in agreement here. Unit tests and REPLs serve different purposes and are poor substitutes for each other; red_admiral was arguing that unit tests obviate the need for REPLs.
>I've seen various attempts of this over the years, but quickly your code becomes more complex than the computer can run while you type and you fall back to running most of the tests after in some way.
That does not match my experience with lisp.
Mine, either.
The best is kind of debatable as it lacks the IDE tooling from LispWorks and Allegro.
>The best is kind of debatable
I used the word "arguably" in the very first word of that sentence:
>Arguably the best is SBCL
The word arguable is a synonym for the word debatable.
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'.
This is the double edged sword of particularly extensible customizable languages is that they invariably won't produce a robust ecosystem of packages that can compose with each other in the manner of pip/npm/crates
>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
Yeah, and I despise it. :D I purposefully expose the lede in my own articles early and often and as up front as I can make it - the editorial reviews keep saying "you should optimize for the clix, maing!" and ... no. If someone doesn't want to read the crap I come up with, I want them to know they don't want to read it right out of the gate, personally.
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.
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++ succeeded twice.
Initially, it provided a thin object-oriented abstraction over C. This solved many problems scaling large C projects. It set baseline expectations for languages that came later. Being a "thin object-oriented abstraction over C" has significant limits. By the 2000s, it was clear that C++ couldn't scale complexity in the way we needed it to. It was slowly dying.
C++ reinvented itself as a functional metaprogramming language starting with C++11, providing an even higher level of abstraction. Many deficiencies in the older language and systems languages generally were addressed. This was a huge success, creating a large resurgence in adoption and setting new expectations for what a systems language should be capable of. C++20 looks like a completely different (and much better) language than C++98.
I view C -> legacy C++ -> modern C++ as the evolution of a single language. Each was wildly successful on its own up to some level of complexity. Every time it runs into a practical limitations on scaling complexity, it adds a new layer of abstraction. As much as people complain about it, this strategy has clearly been successful.
I don't think C++ succeeded because it was object-oriented. I think C++ was object-oriented because classes were an abstraction that could layer on top of C with fairly low overhead, giving it more expressive power without much mandatory cost to size or speed.
In other words, object-orientation was the means, not the end.
Back then OOP was all the hype and inheritance was cool.
C++ predated the OOP hype cycle and triggered, or at least accelerated it.
Agreed and that's probably the second major killer feature of C++.
> python succeeded because it wasn't Perl's TMTOWTDI, everyone expected ruby to overtake python, but .. for some reason that never happened
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.
To have a theory of success, you have to also be able to explain failure. Why did object-oriented C (aka C++) take off but object-oriented Pascal (aka Delphi) not, despite the fact that Pascal was as prevalent as C in those days? Why was Python able to overturn Perl's dominance in the scripting space, but Ruby was unable to do so? Why did Ada and Smalltalk never achieve significant dominance?
A lot of success does come down to being in the right place at the right time. JS was successful because it was the only available scripting language for the web (although MS pushed VBScript for a bit) when there was a concerted effort to kill off the Java and Flash plugins. C was successful because it was tied to the Unix OS, which happened to overtake other OSes for a variety of reasons.
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.
Yeah, this is a more honest assessment than the others I've read here.
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.
Java came with Applets/Web, VB and Delphi with Windows, TP with cheap compilers for PC on top of Pascal university adoption,....
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.
Javascript didn't need a plugin, unlike Java, and could directly alter the page contents. One of the first heavy uses was Google Maps, interactive JS-based applications took off at that point. Then with an army of web developers (meaning in browser), Node took off when it handed them a way to work on the backend in the same language.
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.
Gmail was the original AJAX woah! JavaScript application.
Somewhat ironic, since AJAX was originally created by Microsoft to implement the Outlook web client.
Microsoft was early and late to lots of things. They dominated early smartphones, too.
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).
JS despite its (many) faults still allowed a fairly functional style way before that was mainstream. Java and C++ only got lambdas decades later.
Let's be real here. JavaScript didn't take off because it was functional in the functional programming sense. It took off because it was built in and procedural. You didn't need to muck around with objects if you were a total noob. You'd just write your functions and call them with strings as parameters.
Javascript took off because it was your only option for a lot of things. Flash and Java tried, but both were always hit and miss as to who could use it. Everybody had javascript in their browser so you had no choice if you were to reach them but meet them where they were.
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.
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.
I think in terms of niches and fitness
Programming languages are under a Darwinism-like pressure of programmer's attention. They have to fit a niche, and the ones that fit the niche best, survive. What another commentator calls killed features is, to me, a way to fit a niche.
Sometimes that niche is fun, like Python. Javascript's niche is that it's literally the only option. I suspect some languages (Java) fill a niche because they've been there for so long there's no oxygen for anything else to have a chance.
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
All languages are fun, but the most fun programming languages are ACPUL, Lisp and fun esoteric languages like Brainfuck. Enterprise made programming less fun while the most popular languages are popular mainly because huge budgets are allocated not only to promote them across every platform, but also to pay salaries.
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.
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?
All of them are respectable. I've done most of those - Icon's new for me, and I don't think I've ever written anything in Ada either although I've come unfortunately close thanks to industrial requirements. I escaped!
And yes, awk is a programming language. And respectable. I tend not to use it much any more, but that's because there are other things that feel easier than remembering the syntax. C'est la vie.
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).
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.
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.
> 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
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.
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.
> 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.
> 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.)
Yeah, definitely on point. I use AI for code generation, but I ride herd on it quite a lot and I limit scope viciously and with hard rules about what the models are even allowed to generate. It's worked out pretty well, but it's hardly the "oh send a question get a full system back" that people try to pretend it is.
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.
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.
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.
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
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.
exiftool is still best in class in its arena.
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.
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.
ObjC "failed" because it was locked inside the Apple ecosystem, and Apple made no serious effort to change that. Ref counting aside, I thought it was a wonderful fun language. But it was always platform specific in a way that other languages aren't.
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.
> Yet I'd say that it's relatively rare (while being completely absent in my experience) that anyone would choose ObjC today
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.
Well, the problem here is in your own words: you say `My belief is` - and so it is. I cannot and would never presume to tell you what you believe. Yet I believe otherwise. Swift won on multiple axes; ObjC is still around but feels like legacy to me, much like Pascal does: influential (heck, I use ObjC terminology when describing OO concepts, over Smalltalk!) but not, like, a living language at this point even though its death might be, um, a lot more rumor than fact.
> ObjC is still around but feels like legacy to me
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.
And yes, you're absolutely right. Apple is making a choice here, and they absolutely have impact on what the developers "get to use" - much as .Net succeeds largely to vendor choices on Windows, too. And developers get to suck it up! That's the three axis thing again: vocation, art, job. Swift and .Net both got a huge kick from the "job" department. That's how it goes.
> That's the three axis thing again: vocation, art, job. Swift and .Net both got a huge kick from the "job" department.
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 wrote that it was awkward because IMO it was. That is indeed "my opinion" - I found the language it used to express concepts far more useful than the language itself, and found myself writing C++ far more often than ever wanting to write ObjC.
It's unclear whether your last comment is talking about the art or the job axis, the latter of which I just asked about.
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.
[dead]
> Different diseases, one pathology.
> 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.
Here's another one of my favorites: pulling a huge weed out of soft, loose soil and hearing the crackle of the roots as they come up out of the earth.
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...
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.
Boom: JavaScript
Bust: Python
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.
Has been trivial to do for 10+ years. Next you’re gonna say I need RN or Expo to write JS for iOS.
JS ecosystem = capitalism, websites, payments
Python = math, language, theory
How did all of the capitalism get to be JavaScript?
Let's keep ourselves a bit grounded.
No, payments certainly don't run on JavaScript, unless all you know about payment systems are the web frontends.
If you knew anything about payment systems, you'd know you get a nonce or receiptID and it is a front-end only thing. You don't do the backend banking yourself.
Maybe your backend sends an email, or saves the receipt, but that's peripheral.
The entire Payments flow is front-end capture, then the service doing all the actual backend payment part. It's a black box from your end and you can decide to do it entirely front-end if you wanted. There's no way around it.