Yet it has relatively fast compilers, than a couple of modern languages, even on aging hardware versus the gaming rigs required for those modern languages.
I wonder if there's some type of generational amnesia where the subjective definition of what constitutes fast gets slower and slower with time, where communicating ones frustration with slow software is met with comments about how software is not actually slow.
Modern languages generally have much fancier type systems (Algol 60 didn't even have records!). Perhaps more importantly, modern compilers do optimizations that I doubt anyone back in 1960s even dreamed of.
> Edit: OpenVMS maybe, but not sure whether that qualifies for in wider use
In the x86-64 port, they've been moving OpenVMS to use LLVM too. With the VAX->Alpha port, DEC introduced a common backend for all their OpenVMS compilers, called "GEM". For the Alpha->Itanium port, Compaq/HP kept the GEM backend but modified it to generate Itanium code instead of Alpha.
For the x86-64 port, instead of investing in modifying "GEM" to support x86-64, VSI decided to use LLVM as a backend, and then write a translator from GEM's intermediate representation to LLVM's. So they keep the same frontends as before – except for C++, where they replaced the EDG/Intel frontend with LLVM – but now use LLVM as a backend. https://llvm.org/devmtg/2017-10/slides/Reagan-Porting%20Open...
OpenVMS has a somewhat unusual ABI. For x86-64 they've tried to make it more consistent with the standard Linux x86-64 ABI, but there remain some distinctive features. One feature (which I actually really like, I think it is a shame that other ABIs don't do this), is that variadic function calls pass the argument count in a register (%rax on x86-64). Another is that all functions must have a 32-bit address; the code of a function can be allocated above 4GB, but they allocate a trampoline under 4GB which jumps to its actual code – this was done to simplify interoperability between 32-bit and 64-bit code in the same address space. https://docs.vmssoftware.com/vsi-openvms-calling-standard
IBM still has their classic XL C/C++ compilers for AIX, IBM i and mainframe, but they've been converging to LLVM. I believe the pre-LLVM versions share a common backend with some of their other language compilers (COBOL, PL/I, PL/X, PL.8, etc), ultimately going back to work of their Toronto and Yorktown labs starting in the 1980s. More recently they've started replacing their C/C++ frontends with LLVMs, while keeping their own backend; and even more recently swapping out their backend for LLVM's too.
Good point. I completely forgot IBM. And I even was a trainee there, when mainframes where a big thing, PCs an exception and nobody including myself had heard about AIX (although technically it was a year old).
Probably not qualifies as "wide use" but embedded compilers like SDCC still matters. Yes, 8-bits are giving way to ARM, but there will be a few more millennia before they are out.
Clang, GCC and MSVC are the big ones, the rest are more or less niche compilers - with Clang and GCC only differing in small details.
(one could argue that MSVC is slowly becoming a niche compiler too - it feels like it's not as important anymore as it was 10..15 years ago, maybe because a lot of new C/C++ programmers seem to start on Linux, not Windows - that's at least the 'general vibe' I'm getting)
Currently, zig cc is the Clang frontend which is linked into the Zig compiler (most things in that blog post are about differences between the Zig toolchain and a typical Clang toolchain for cross-compilation, and how Zig invokes the Clang frontend).
I'm not sure what the current plan is for C compilation after the LLVM divorce and after Clang will be moved into a Zig package (e.g. I remember talk that arocc [1] is going to be integrated into the Zig compiler, but not sure if that's still planned, or if C compilation will also be delegated to the new Clang package along with C++ and ObjC compilation).
One cool thing about Algol is that, while the language itself is over 60 years old, most modern programmers can have a decent understanding of source code written in it. It's a bit like reading 17th century English. You don't quite understand everything, but you can grasp most of it.
I wonder why the retrocomputing crowd hasn't done much in ALGOL. Perhaps because it's just easier to write in BASIC, which was influenced by it.
Assuming we're talking about Algol 60, it really depends on what kind of source code. When you look at the more creative applications of call-by-name, for example, it looks utterly alien. Or stuff like label arguments and switches.
OTOH if you disregard those, the rest is simple to understand because there isn't much of it. E.g. there's a grand total of three types: integer, real, and Boolean. There are no structs, pointers, or really any derived types (it has arrays, but they aren't technically types but rather an orthogonal property of variables).
But, for the same reason, it's not particularly useful. The lack of pointers especially limits what you can do with it, even if you use it for its original primary purpose (reference implementations of algorithms).
Probably because of the mix with nostalgia, and the folks that would be nostalgic about Algol 60 hardly care about computers nowadays.
When I was a kid, the systems that we cared about were 8 bit home systems, starting with anything CP/M, and then there was the whole big machines being used at universities and our parents jobs, which we only knew from computer magazines.
Spaniard here; Spanish is like Lisp. Reading 17th century Spanish is almost a no brainer minus some Medieval knights' jargon (put from Cervantes on purpose on making fun on old-farts) and some 17th jargon too, specially from popular sayings just said in La Mancha region which are still in use because they are related to daily farm/fields/food but the rest of Spain has no clear references off.
Also the RAE institution for the Spanish Language does something similar to SRFI's + RSR?s for Scheme.
IIRC Algol was already dead and buried in the 80's, it certainly wasn't relevant or even available on most computer systems an 80's teenager had access to. The most popular high level language on 8-bit home computers was certainly BASIC, for compiled languages probably some dialect of PASCAL, and maybe FORTH for something entirely different.
BASIC didn't have to be a bad choice either, Acorn/BBC BASIC even had proper inline assembly.
It was pretty much dead by the mid-70s. PASCAL, C, FORTRAN, and COBOL killed it on mainframes + minis and it was too complex for micros. (Thus - BASIC.)
The twitching corpse lived on in the form of JOVIAL for DOD work (until ADA happened), and CORAL persisted in the UK because of bureaucratic momentum. Simula was another derivative that lasted for a while.
But C and PASCAL were better, simpler, equally productive languages. As soon as they appeared ALGOL 60 didn't really need to exist any more. And ALGOL 68 was an ALGOL too far.
I think ALGOL nowadays would likely work best as sort of a lingua franca psuedocode, I don’t think it would be too difficult to make that work. It kind of was already for a long time, as much of the Collected Algorithms of the ACM were originally written in it IIRC.
With a few exceptions (like APL), I've always found it pretty easy to read code in most languages, as long as I understood the paradigm, and the original author made at least a tiny effort to use sensible naming.
Imperative languages only have a handful of concepts, like variables, type declaration, looping, branching, function call, etc. and the language and the context generally make those pretty easy to identify.
The other language types (functional, forth-like, etc.) have similar (but often different) concepts, and once you understand the concept and can see it through the syntax, it's pretty easy to follow along.
Writing new code in a new language is the difficult part.
Key Innovations Introduced by ALGOL 60:
Block Structure: It introduced the concept of structuring code into blocks, which paved the way for modular programming.
Formal Syntax: ALGOL 60 used Backus-Naur Form (BNF) to formally define its syntax, setting a standard for future language specifications.
Recursion: It supported recursive function calls, which was revolutionary at the time.
Lexical Scoping: It allowed nested functions and controlled variable scope.
Platform Independence: It aimed to be machine-independent, making it suitable for documenting algorithms.
My friend Colin Broughton completed the first full implementation of the Algo68 spec. Apparently there was some concern that it was not going to be implementable!
Reading the ALGOL 68 spec[1] today, it feels like complexity is mainly about the unusual verbiage used (which, as I understand, was equally unusual at the time, being introduced specifically for it). The language itself is pretty mundane by modern standards.
Readit News
https://www.masswerk.at/algol60/report.htm
Call by name in particular can be very tricky, especially where it intersects with higher-order functions.
It can also be interesting to read contemporary discussions of problematic spots in the language, e.g.:
https://dl.acm.org/doi/10.1145/366193.366209
https://dl.acm.org/doi/10.1145/363717.363743
And the original ALGOL bulletin which has committee reports and mailing lists for the design process:
https://archive.computerhistory.org/resources/text/algol/alg...
Besides "call by name", also using gotos for dynamic non-local exits, even by passing labels as an argument to a procedure, is pretty tricky.
Not really working in the area and did not research now, but I can come up with:
* gcc
* clang
* Microsoft probably has their own implementation
* Intel probably still has their own implementation
* ?
Edit: OpenVMS maybe, but not sure whether that qualifies for in wider use
Edit2: ARM of course
Back in 2021, Intel moved the back end of their compiler toolchain to LLVM . Intel still has their own proprietary front end (icpx).
https://www.google.com/search?q=intel+compiler+llvm+adoption
https://www.intel.com/content/www/us/en/developer/articles/g...
EDG used to be the gold standard of ISO conformance.
In the x86-64 port, they've been moving OpenVMS to use LLVM too. With the VAX->Alpha port, DEC introduced a common backend for all their OpenVMS compilers, called "GEM". For the Alpha->Itanium port, Compaq/HP kept the GEM backend but modified it to generate Itanium code instead of Alpha.
For the x86-64 port, instead of investing in modifying "GEM" to support x86-64, VSI decided to use LLVM as a backend, and then write a translator from GEM's intermediate representation to LLVM's. So they keep the same frontends as before – except for C++, where they replaced the EDG/Intel frontend with LLVM – but now use LLVM as a backend. https://llvm.org/devmtg/2017-10/slides/Reagan-Porting%20Open...
OpenVMS has a somewhat unusual ABI. For x86-64 they've tried to make it more consistent with the standard Linux x86-64 ABI, but there remain some distinctive features. One feature (which I actually really like, I think it is a shame that other ABIs don't do this), is that variadic function calls pass the argument count in a register (%rax on x86-64). Another is that all functions must have a 32-bit address; the code of a function can be allocated above 4GB, but they allocate a trampoline under 4GB which jumps to its actual code – this was done to simplify interoperability between 32-bit and 64-bit code in the same address space. https://docs.vmssoftware.com/vsi-openvms-calling-standard
IBM still has their classic XL C/C++ compilers for AIX, IBM i and mainframe, but they've been converging to LLVM. I believe the pre-LLVM versions share a common backend with some of their other language compilers (COBOL, PL/I, PL/X, PL.8, etc), ultimately going back to work of their Toronto and Yorktown labs starting in the 1980s. More recently they've started replacing their C/C++ frontends with LLVMs, while keeping their own backend; and even more recently swapping out their backend for LLVM's too.
(one could argue that MSVC is slowly becoming a niche compiler too - it feels like it's not as important anymore as it was 10..15 years ago, maybe because a lot of new C/C++ programmers seem to start on Linux, not Windows - that's at least the 'general vibe' I'm getting)
[1] https://andrewkelley.me/post/zig-cc-powerful-drop-in-replace...
I'm not sure what the current plan is for C compilation after the LLVM divorce and after Clang will be moved into a Zig package (e.g. I remember talk that arocc [1] is going to be integrated into the Zig compiler, but not sure if that's still planned, or if C compilation will also be delegated to the new Clang package along with C++ and ObjC compilation).
[1] https://github.com/Vexu/arocc
I’m not sure how many independent compiler backends are widely used with those frontends and stdlibs.
I wonder why the retrocomputing crowd hasn't done much in ALGOL. Perhaps because it's just easier to write in BASIC, which was influenced by it.
OTOH if you disregard those, the rest is simple to understand because there isn't much of it. E.g. there's a grand total of three types: integer, real, and Boolean. There are no structs, pointers, or really any derived types (it has arrays, but they aren't technically types but rather an orthogonal property of variables).
But, for the same reason, it's not particularly useful. The lack of pointers especially limits what you can do with it, even if you use it for its original primary purpose (reference implementations of algorithms).
When I was a kid, the systems that we cared about were 8 bit home systems, starting with anything CP/M, and then there was the whole big machines being used at universities and our parents jobs, which we only knew from computer magazines.
Also the RAE institution for the Spanish Language does something similar to SRFI's + RSR?s for Scheme.
BASIC didn't have to be a bad choice either, Acorn/BBC BASIC even had proper inline assembly.
The twitching corpse lived on in the form of JOVIAL for DOD work (until ADA happened), and CORAL persisted in the UK because of bureaucratic momentum. Simula was another derivative that lasted for a while.
But C and PASCAL were better, simpler, equally productive languages. As soon as they appeared ALGOL 60 didn't really need to exist any more. And ALGOL 68 was an ALGOL too far.
Imperative languages only have a handful of concepts, like variables, type declaration, looping, branching, function call, etc. and the language and the context generally make those pretty easy to identify.
The other language types (functional, forth-like, etc.) have similar (but often different) concepts, and once you understand the concept and can see it through the syntax, it's pretty easy to follow along.
Writing new code in a new language is the difficult part.
[1] https://en.wikipedia.org/wiki/Man_or_boy_test
Formal Syntax: ALGOL 60 used Backus-Naur Form (BNF) to formally define its syntax, setting a standard for future language specifications.
Recursion: It supported recursive function calls, which was revolutionary at the time.
Lexical Scoping: It allowed nested functions and controlled variable scope.
Platform Independence: It aimed to be machine-independent, making it suitable for documenting algorithms.
https://en.wikipedia.org/wiki/FLACC
[1] http://www.math.bas.bg/bantchev/place/algol68/a68rr.html