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".
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?
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.
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.
Instead now, you throw everything away when moving to a new language ecosystem. Would love to see parts of languages become aligned in the same manner that CPUs did, so some constructs become portable and compatible between languages.
Another fascinating aspect of COBOL is that it's the one programming language that actively rejected ALGOL influence. There are no functions or procedures, no concept of local variables. In general, no feature for abstraction at all, other than labelled statements. Block-structured control flow (conditionals and loops) was only added in the late 80s.
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.
Did Forth inspire the stack-based VMs of python and java? I don't know about that part of CS history well, but a very large proportion of all code runs on stack based byte code interpreters.
Didn't they take their array programming from Fortran? The Fortran, numpy and matlab array syntaxes are basically identical, down to broadcasting and reduction rules.
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)
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.
Classic HN. A comment meant in half jest is dissected technically and literally and down voted. LOL Anyways, I'm glad the Perl crowd is alive and well!
"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"
>An accurate analysis of the fall of Pascal would be longer than the rest of this essay.
I put the blame solely on the management of Borland. They had the world leading language, and went off onto C++ and search of "Enterprise" instead of just riding the wave.
When Anders gave the world C#, I knew it was game over for Pascal, and also Windows native code. We'd all have to get used to waiting for compiles again.
Wow, that was a trip down memory lane! I have used six of those languages: BASIC, APL, COBOL, Pascal, Algol-W (a derivative of Algol 60), PL/1. Mostly in school. My first dollars earned in software (brief consulting gig in grad school) had me debug a PL/1 program for a bank.
For some reason I remember an odd feature of PL/1: Areas and offsets. If I am remembering correctly, you could allocate structures in an area and reference them by offset within that area. That stuck in my mind for some reason, but I never found a reason to use it. It struck me as a neat way to persist pointer-based data structures. And I don't remember seeing the idea in other languages.
Maybe the reason it stayed with me is that I worked on Object Design's ObjectStore. We had a much more elegant and powerful way of persisting pointer-based structures, but an area/offset idea could have given users some of the capabilities we provided right in the language.
Serious question: Is Ada dead? I actually had to google Ada, and then "Ada language" to find out. It's not dead, and it has a niche.
When I was in grad school in the late 70s, there was a major competition to design a DoD-mandated language, to be used in all DoD projects. Safety and efficiency were major concerns, and the sponsors wanted to avoid the proliferation of languages that existed at the time.
Four (I think) languages were defined by different teams, DoD evaluated them, and a winner was chosen. It was a big thing in the PL community for a while. And then it wasn't. My impression was that it lost to C. Ada provided much better safety (memory overruns were probably impossible or close to it). It would be interesting to read a history of why Ada never took off the way that C did.
Wheee does perk fit in this scheme of dying languages. I see fewer and fewer new packages written in Perl and lots of unmaintained packages in Cpan. It seems obvious that the language is dying a slow death .
Algol-68 gets a bum rap here - it brought us 'struct', 'union' (and tagged unions) a universal type system, operator declarations, a standard library, and a bunch more - Wirth worked on the original design committee, Pascal reads like someone implementing the easy parts of Algol-68.
The things it got wrong were mostly in it having a rigorous mathematical definition (syntax and semantics) that was almost unreadable by humans ... and the use of 2 sets of character sets (this was in the days of cards) rather than using reserved words
> Of the four mother languages, ALGOL is the most "dead"; Everybody still knows about LISP, COBOL still powers tons of legacy systems, and most scientific packages still have some FORTRAN.
I've heard of enough Cobol and Fortran jobs existing, and Lisp continues to exist in some form or other, but Algol really does seem dead. I remember someone telling me about an Algol codebase that was decommissioned in 2005 and that seemed like a very late death for an Algol codebase.
Unisys still actively maintains their MCP mainframe operating system, which is written in an Algol superset (ESPOL/NEWP), and comes with a maintained Algol compiler - https://public.support.unisys.com/aseries/docs/ClearPath-MCP... - and they continue to add new features to Algol (even if minor)
So, no, Algol isn’t dead. Getting close but still not quite there. There are better candidates for dead languages than Algol, e.g. HAL/S (programming language used for the Space Shuttle flight software)
There are some legacy programs in DoD that are developed in a variant of Algol 58 called JOVIAL that are still supported and edited despite over 40 years now of mandate to update to something newer (Ada). Also used in some other places, like UK Air Traffic Control at least until 2016 (that was the last date I've seen for replacement plan)
In the Smalltalk section, it says that Python isn't 'true' OO like Smalltalk... who considers this to be the case? In Python, everything (including functions, and classes), is an object
I think this comes from the fact, that Alan Kay does not think it is OO. There is no legal definition, but Python does other have Smalltalk-like 'method_missing' or 'responds_to' methods. If you think OOP means messages and late-binding, that feature is important.
In the finance world COBOL is still very much not dead. It's not as dominant as it once was, but core mainframe code is very often still COBOL.
Replacing that is a very hard problem as thousands and thoudands of (abused and overloaded) integrations are layered in serveral strata around it relying each night on exact behaviour in the core, warts and all.
As for Smalltalk, I know at least one company around hete still running some legacy, but still maintained afaik, code on it ( https://mediagenix.tv ).
57 comments
[ 2.1 ms ] story [ 88.9 ms ] threadPascal, particularly the Delphi/Object Pascal flavor, is also still in widespread use today.
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.
you need special custom numerical types to come even close in, say, java or C++ or any other language.
(There are a few other threads with a smaller number of comments.)
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.
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.
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"
I put the blame solely on the management of Borland. They had the world leading language, and went off onto C++ and search of "Enterprise" instead of just riding the wave.
When Anders gave the world C#, I knew it was game over for Pascal, and also Windows native code. We'd all have to get used to waiting for compiles again.
For some reason I remember an odd feature of PL/1: Areas and offsets. If I am remembering correctly, you could allocate structures in an area and reference them by offset within that area. That stuck in my mind for some reason, but I never found a reason to use it. It struck me as a neat way to persist pointer-based data structures. And I don't remember seeing the idea in other languages.
Maybe the reason it stayed with me is that I worked on Object Design's ObjectStore. We had a much more elegant and powerful way of persisting pointer-based structures, but an area/offset idea could have given users some of the capabilities we provided right in the language.
When I was in grad school in the late 70s, there was a major competition to design a DoD-mandated language, to be used in all DoD projects. Safety and efficiency were major concerns, and the sponsors wanted to avoid the proliferation of languages that existed at the time.
Four (I think) languages were defined by different teams, DoD evaluated them, and a winner was chosen. It was a big thing in the PL community for a while. And then it wasn't. My impression was that it lost to C. Ada provided much better safety (memory overruns were probably impossible or close to it). It would be interesting to read a history of why Ada never took off the way that C did.
The things it got wrong were mostly in it having a rigorous mathematical definition (syntax and semantics) that was almost unreadable by humans ... and the use of 2 sets of character sets (this was in the days of cards) rather than using reserved words
I've heard of enough Cobol and Fortran jobs existing, and Lisp continues to exist in some form or other, but Algol really does seem dead. I remember someone telling me about an Algol codebase that was decommissioned in 2005 and that seemed like a very late death for an Algol codebase.
Unisys still actively maintains their MCP mainframe operating system, which is written in an Algol superset (ESPOL/NEWP), and comes with a maintained Algol compiler - https://public.support.unisys.com/aseries/docs/ClearPath-MCP... - and they continue to add new features to Algol (even if minor)
So, no, Algol isn’t dead. Getting close but still not quite there. There are better candidates for dead languages than Algol, e.g. HAL/S (programming language used for the Space Shuttle flight software)
Replacing that is a very hard problem as thousands and thoudands of (abused and overloaded) integrations are layered in serveral strata around it relying each night on exact behaviour in the core, warts and all.
As for Smalltalk, I know at least one company around hete still running some legacy, but still maintained afaik, code on it ( https://mediagenix.tv ).