There is one very BIG thing that Cobol pioneered: the requirement that not only the programs, but also the data, must be portable across machines. At a time when machines used different character codes, let alone different numeric formats, Cobol was designed to vastly reduce (though it did not completely eliminate) portability woes.
We take this for granted now, but at the time it was revolutionary. In part, we've done things like mandating Unicode and IEEE 754, but nowadays most of our languages also encourage portability. We think very little of moving an application from Windows on x86_64 to Linux on ARMv8 (apart from the GUI mess), but back when Cobol was being created, you normally threw your programs away (“reprogramming”) when you went to a new machine.
I haven't used Cobol in anger in 50 years (40 years since I even taught it), but for that emphasis on portability, I am very grateful.
the other big cobol feature is high precision (i.e. many digest) fixed point arithmetic. not loosing pennies on large sums, and additionally with well defined arithmetics, portably so as you point out, is a killer feature in finance.
you need special custom numerical types to come even close in, say, java or C++ or any other language.
>the other big cobol feature is high precision (i.e. many digest) fixed point arithmetic. not loosing pennies on large sums, and additionally with well defined arithmetics, portably so as you point out, is a killer feature in finance.
I guess you mean:
>digest -> digits
>loosing -> losing
Is that the same as BCD? Binary Coded Decimal. IIRC, Turbo Pascal had that as an option, or maybe I am thinking of something else, sorry, it's many years ago.
Okay, I'll bite. ML did not mostly die, it morphed into two main dialects, SML and OCaml. OCaml is still going strong, and it's debatable whether SML is mostly dead.
My main beef, however, is that the last sentence in the section seems to suggest that the birth of Haskell killed SML on the vine because suddenly everybody only wanted pure, lazy FP. That's just wrong. The reality is that these two branches of Functional Programming (strict/impure and lazy/pure) have continued to evolve together to the present day.
"Significance: In terms of syntax and semantics we don’t see much of COBOL in modern computing."
Would I be wrong in saying that SQL has what feels to me to be a very cobaly syntax. By which I mean, I know it is not directly related to cobal, But someone definitely looked at cobal's clunky attempt at natural language and said "that, I want that for my query language"
Modula-3 should be on that list as well.
Unfortunately pretty dead (compiler support is rather abysmal), though pretty influential. Wikipedia lists a couple of languages that it influenced, I think it should also include Go (though Go is allegedly influenced by Modula-2, according to its wikipedia article)
One of the most significant new COBOL projects in 2025 was the integration of a new COBOL front-end into the GNU Compiler Collection. There are indeed quite many new projects being started in COBOL, though they primarily focus on modernization and integration with contemporary technologies rather than traditional greenfield development. Also not forget some cloud providers now offer "COBOL as a service" (see e.g. https://docs.aws.amazon.com/m2/latest/userguide/what-is-m2.h...).
By "new COBOL projects" I mean green-field development of entirely new projects written in that language - not the continued development of existing COBOL codebases, or development of tools which interact with COBOL code.
As an aside, the article you linked to is pretty obvious AI slop, even aside from the image ("blockchin infarsucture" and all). Some of the details, like claims that MIT is offering COBOL programming classes or that banks are using COBOL to automatically process blockchain loan agreements, appear to be entirely fabricated.
> There are indeed quite many new projects being started in COBOL
No.
You have to put this relative to projects started in other languages, at which points new projects started in COBOL is even less than a rounding error, it probably wouldn't result in anything other than 0 with a float.
And everyone with relevant fintech project experience knows that new projects on the existing core banking systems are started all the time and that COBOL continues to be a relevant language (whether we like it or not).
Maybe their definition uses recent popularity or how many new projects are started with it. Under that definition, I think it's pretty safe to call it "dead".
Yes. "Dead" normally means "to be devoid of life," but it's often extended to metaphorically cover things like computer languages.
edit: for ancient Greek to become a dead language, will we be required to burn all of the books that were written in it, or can we just settle for not writing any new ones?
Interesting read, and would have been good to see the author’s definition of ‘mostly dead’. Some are still used widely in niche areas like COBOL for banking. If a language itself isn’t receiving any updates nor are new packages being developed by users, is it mostly dead?
In any case, the author claims that each of these languages is "dead". There is a "Cause of Death" section for each language, which doesn't allow for another conclusion. By listing languages like ALGOL, APL, CLU, or Simula, the author implies that he means by "dead" "no longer in practical use, or just as an academic/historic curiosity". The article contradicts itself by listing languages like COBOL, BASIC, PL/I, Smalltalk, Pascal, or ML, for which there is still significant practical use, even with investments for new features and continuation of the language and its applications. The article actually disqualifies by listing COBOL or Pascal as "mostly dead", because there is still a large market and significant investment in these languages (companies such as Microfocus and Embarcadero make good money from them). It is misleading and unscientific to equate “no longer mainstream” with “no longer in use.” This makes the article seem arbitrary, poorly researched, and the author not credible.
R/S is also heavily influenced by Lisp. Haven’t written it in 10 years, but AFAIR it even has proper macros where argument expressions are passed without evaluation.
Seeing Smalltalk on these lists and not Self always seems... lacking. Besides its direct influence on Smalltalk, and its impact on JIT research, its prototype-based object system lead to Javascript's object model as well.
Forth was neat, but it was a bit of an evolutionary dead end. I'm not aware of any significant concepts from Forth which were adopted by other, later programming languages.
RPL (Reverse Polish Lisp, a high level language for HP calculators) possibly drew on it a bit, though the main antecedents are RPN and Lisp, and possibly Poplog (a Poplog guru was at HP at the time, but I don't know if he contributed).
Imho Lisp is deader than COBOL. Especially now that we've learned you can do the really hard and interesting bits of AI with high-performance number crunching in C++ and CUDA.
There is one very BIG thing that Cobol pioneered: the requirement that not only the programs, but also the data, must be portable across machines. At a time when machines used different character codes, let alone different numeric formats, Cobol was designed to vastly reduce (though it did not completely eliminate) portability woes.
We take this for granted now, but at the time it was revolutionary. In part, we've done things like mandating Unicode and IEEE 754, but nowadays most of our languages also encourage portability. We think very little of moving an application from Windows on x86_64 to Linux on ARMv8 (apart from the GUI mess), but back when Cobol was being created, you normally threw your programs away (“reprogramming”) when you went to a new machine.
I haven't used Cobol in anger in 50 years (40 years since I even taught it), but for that emphasis on portability, I am very grateful.
the other big cobol feature is high precision (i.e. many digest) fixed point arithmetic. not loosing pennies on large sums, and additionally with well defined arithmetics, portably so as you point out, is a killer feature in finance.
you need special custom numerical types to come even close in, say, java or C++ or any other language.
>the other big cobol feature is high precision (i.e. many digest) fixed point arithmetic. not loosing pennies on large sums, and additionally with well defined arithmetics, portably so as you point out, is a killer feature in finance.
I guess you mean:
>digest -> digits
>loosing -> losing
Is that the same as BCD? Binary Coded Decimal. IIRC, Turbo Pascal had that as an option, or maybe I am thinking of something else, sorry, it's many years ago.
Okay, I'll bite. ML did not mostly die, it morphed into two main dialects, SML and OCaml. OCaml is still going strong, and it's debatable whether SML is mostly dead.
My main beef, however, is that the last sentence in the section seems to suggest that the birth of Haskell killed SML on the vine because suddenly everybody only wanted pure, lazy FP. That's just wrong. The reality is that these two branches of Functional Programming (strict/impure and lazy/pure) have continued to evolve together to the present day.
"Significance: In terms of syntax and semantics we don’t see much of COBOL in modern computing."
Would I be wrong in saying that SQL has what feels to me to be a very cobaly syntax. By which I mean, I know it is not directly related to cobal, But someone definitely looked at cobal's clunky attempt at natural language and said "that, I want that for my query language"
Modula-3 should be on that list as well. Unfortunately pretty dead (compiler support is rather abysmal), though pretty influential. Wikipedia lists a couple of languages that it influenced, I think it should also include Go (though Go is allegedly influenced by Modula-2, according to its wikipedia article)
What other languages have been influenced by Go?
How can COBOL be a "dead" or "mostly dead" language if it still handles over 70% of global business transactions (with ~800 billion lines of code and still growing). See e.g. https://markets.businessinsider.com/news/stocks/cobol-market....
BASIC is the scripting language used by Microsoft Office. Saying that it powers millions of businesses is probably not an exaggeration.
Pascal, particularly the Delphi/Object Pascal flavor, is also still in widespread use today.
Also Smalltalk is still in wide use; ML is also used; there are even many PL/I applications in use today and IBM continues to give support.
I don't know, I heard somewhere that even the C language is in wide use, still ... ;)
No one's starting new projects in COBOL.
One of the most significant new COBOL projects in 2025 was the integration of a new COBOL front-end into the GNU Compiler Collection. There are indeed quite many new projects being started in COBOL, though they primarily focus on modernization and integration with contemporary technologies rather than traditional greenfield development. Also not forget some cloud providers now offer "COBOL as a service" (see e.g. https://docs.aws.amazon.com/m2/latest/userguide/what-is-m2.h...).
By "new COBOL projects" I mean green-field development of entirely new projects written in that language - not the continued development of existing COBOL codebases, or development of tools which interact with COBOL code.
As an aside, the article you linked to is pretty obvious AI slop, even aside from the image ("blockchin infarsucture" and all). Some of the details, like claims that MIT is offering COBOL programming classes or that banks are using COBOL to automatically process blockchain loan agreements, appear to be entirely fabricated.
> There are indeed quite many new projects being started in COBOL
No.
You have to put this relative to projects started in other languages, at which points new projects started in COBOL is even less than a rounding error, it probably wouldn't result in anything other than 0 with a float.
The claim was "No one's starting new projects in COBOL."
And everyone of good faith understood what the claim actually was.
And everyone with relevant fintech project experience knows that new projects on the existing core banking systems are started all the time and that COBOL continues to be a relevant language (whether we like it or not).
Maybe their definition uses recent popularity or how many new projects are started with it. Under that definition, I think it's pretty safe to call it "dead".
If you redefine language, anything is possible.
Yes. "Dead" normally means "to be devoid of life," but it's often extended to metaphorically cover things like computer languages.
edit: for ancient Greek to become a dead language, will we be required to burn all of the books that were written in it, or can we just settle for not writing any new ones?
I was almost sure that Prolog would be on the list, but apparently not.
Because it's dead or because it's influential?
Interesting read, and would have been good to see the author’s definition of ‘mostly dead’. Some are still used widely in niche areas like COBOL for banking. If a language itself isn’t receiving any updates nor are new packages being developed by users, is it mostly dead?
In any case, the author claims that each of these languages is "dead". There is a "Cause of Death" section for each language, which doesn't allow for another conclusion. By listing languages like ALGOL, APL, CLU, or Simula, the author implies that he means by "dead" "no longer in practical use, or just as an academic/historic curiosity". The article contradicts itself by listing languages like COBOL, BASIC, PL/I, Smalltalk, Pascal, or ML, for which there is still significant practical use, even with investments for new features and continuation of the language and its applications. The article actually disqualifies by listing COBOL or Pascal as "mostly dead", because there is still a large market and significant investment in these languages (companies such as Microfocus and Embarcadero make good money from them). It is misleading and unscientific to equate “no longer mainstream” with “no longer in use.” This makes the article seem arbitrary, poorly researched, and the author not credible.
The (literal) first and foremost ASCII descendant of APL was MATLAB.
I feel that the article should have made this a lot more clear - as so many people code along the APL -> Matlab / R (via S) -> NumPy family tree.
R/S is also heavily influenced by Lisp. Haven’t written it in 10 years, but AFAIR it even has proper macros where argument expressions are passed without evaluation.
Seeing Smalltalk on these lists and not Self always seems... lacking. Besides its direct influence on Smalltalk, and its impact on JIT research, its prototype-based object system lead to Javascript's object model as well.
Self was influenced by Smalltalk, not the other way around. Smalltalk was developed in the 1970s. Self in the 1980s.
Thanks for the correction.
One day Perl will be on this list
COBOL - “mostly dead” but still somehow the backbone of the global financial system
Previously: https://news.ycombinator.com/item?id=22690229
(There are a few other threads with a smaller number of comments.)
Kinda surprised to not see Forth listed.
Forth was neat, but it was a bit of an evolutionary dead end. I'm not aware of any significant concepts from Forth which were adopted by other, later programming languages.
RPL (Reverse Polish Lisp, a high level language for HP calculators) possibly drew on it a bit, though the main antecedents are RPN and Lisp, and possibly Poplog (a Poplog guru was at HP at the time, but I don't know if he contributed).
PostScript
Or Lisp. Lisp is definitely not dead, but was definitely very influential.
The article does touch on that:
"COBOL was one of the four “mother” languages, along with ALGOL, FORTRAN, and LISP."
Imho Lisp is deader than COBOL. Especially now that we've learned you can do the really hard and interesting bits of AI with high-performance number crunching in C++ and CUDA.
I wrote Lisp this morning to make Emacs do a thing. In other venues, people use Lisp to script AutoCAD.
Lisp isn't as widely used as, say, Python, but it's still something a lot of people touch every single day.
And Clojure