« Back to home

What makes a language... "dead"?

Posted on

On Hacker News, someone asked if people are still using Pascal in 2023. The responses were mostly of the “of course, Delphi!” flavor. But one response stood out to me, and it was bemoaning that the constant HN hype of new languages that ignores “boring tech” the industry is using the majority of the time (Java, Python, C++ in roughly that order).

I sympathize with the commenter’s point because HN commenters generally continue to have a quite naive view on languages and frameworks. The idea that Nim or Rust or Go or whatever will take over the larger programming world any day now is simply not grounded in the realities of the industry.

However, the comment made me wonder, what does it mean for a language to be “dead”? With continuing support by Embaracadero, some software built on Delphi might just run forever at this point.

Let’s consider the stages of decline for a language or framework.

  1. A technology does not get new adopters. That is, the only people who continue to use it for new projects are those who already use it. New companies would never adopt it.
  2. A technology does not get used on new projects by its existing users. The old projects get supported, while new projects use something else entirely.
  3. The technology is not used anywhere with any significance.

I think people believe stage 3 would be “dead”, but for scaled software that seems unrealistic. By that metric, only truly obsolete languages like ALGOL or AppleSoft BASIC would count, which is pointless to consider.

So I believe we should call only stage 1 “legacy”, and stage 2 “dead.” If a language or framework does not get any new uses, even within its current cohort of users, then it is dead. There is no point in learning or advancing the language because there is no possible value creation in doing so.

By these standards, COBOL, despite currently running a lot of banking software, is dead. Delphi does not get any new adopters, but it might not be dead because existing Delphi users build new stuff in it. That would only make it “legacy.”

Here’s another thought after considering “deadness”: the most important time to start transitioning your stack is somewhere between #1 and #21. In that period, it becomes clear that, sometime in the future, you will be unable to hire software engineers who know the language or framework, but it’s not yet a problem. Once #2 is reached, you won’t be able to find anyone to support your old code, and that’s why there are these stories about 75 year old COBOL programmers getting paid big money to fix bugs.


  1. I would argue that the only reason new companies using modern software have not disrupted some of the industries using dead stacks like COBOL is due to heavy regulation. In a less regulated market, they would have. ↩︎