Happy 60th birthday: Algol 60
Report on the Algorithmic Language ALGOL 60 is the title of a 16-page paper appearing in the May 1960 issue of the Communication of the ACM. Probably one of the most influential programming languages, and a language that readers may never have heard of.
During the 1960s there were three well known, widely used, programming languages: Algol 60, Cobol, and Fortran.
When somebody created a new programming languages Algol 60 tended to be their role-model. A few of the authors of the Algol 60 report cited beauty as one of their aims, a romantic notion that captured some users imaginations. Also, the language was full of quirky, out-there, features; plenty of scope for pin-head discussions.
Cobol appears visually clunky, is used by business people and focuses on data formatting (a deadly dull, but very important issue).
Fortran spent 20 years catching up with features supported by Algol 60.
Cobol and Fortran are still with us because they never had any serious competition within their target markets.
Algol 60 had lots of competition and its successor language, Algol 68, was groundbreaking within its academic niche, i.e., not in a developer useful way.
Language family trees ought to have Algol 60 at, or close to their root. But the Algol 60 descendants have been so successful, that the creators of these family trees have rarely heard of it.
In the US the ‘military’ language was Jovial, and in the UK it was Coral 66, both derived from Algol 60 (Coral 66 was the first language I used in industry after graduating). I used to hear people saying that Jovial was derived from Fortran; another example of people citing the language the popular language know.
Algol compiler implementers documented their techniques (probably because they were often academics); ALGOL 60 Implementation is a real gem of a book, and still worth a read today (as an introduction to compiling).
Algol 60 was ahead of its time in supporting undefined behaviors 😉 Such as: “The effect, of a go to statement, outside a for statement, which refers to a label within the for statement, is undefined.”
One feature of Algol 60 rarely adopted by other languages is its parameter passing mechanism, call-by-name (now that lambda expressions are starting to appear in widely used languages, call-by-name has a kind-of comeback). Call-by-name essentially has the same effect as textual substitution. Given the following procedure (it’s not a function because it does not return a value):
procedure swap (a, b); integer a, b, temp; begin temp := a; a := b; b:= temp end; |
the effect of the call: swap(i, x[i]) is:
temp := i; i := x[i]; x[i] := temp |
which might come as a surprise to some.
Needless to say, programmers came up with ‘clever’ ways of exploiting this behavior; the most famous being Jensen’s device.
The follow example of go to usage appears in: International Standard 1538 Programming languages – ALGOL 60 (the first and only edition appeared in 1984, after most people had stopped using the language):
go to if Ab < c then L17 else g[if w < 0 then 2 else n] |
Orthogonality of language use won out over the goto FUD.
The Software Preservation Group is a great resource for Algol 60 books and papers.
Ahh, the gnarliest bug of my career was due to that…..
I thought I had passed a random number into a function (doing a monte carlo simulation), but every time I referenced the parameter it reevaluated the expression and got _another_ random number.
Somehow that just doesn’t fit ones mental model well… same variable name, different value every time you reference that name.
Took myself and my colleagues ages to spot the issue.
Thanks for a mostly good article on the birth of ALGOL 60. You are right that call-by-name was an advanced feature and it is now making a reappearance in so-called lambdas (after Church’s Lambda Calculus of 1930s). Yes happy 90th lambda calculus, people are finally getting to use it!
John Carter notes a subtle problem he fell into. Indeed that might have set call-by-name back, and I was told “CbN is horrible, don’t use it”. CbN reverted to call-by-reference when the expression was just a single identifier. But this could be used as the target of an assignment := in the called procedure. This had the effect of updating the outer variable (a bad thing in itself) and better subsequent languages forbid any assignment to any parameter.
I was teaching students this week about lambdas in Java. The students seemed to understand it best when I said that the formal parameter used in the called method was more-or-less a text expansion of the lambda expression in the method, notionally like ALGOL-60 did call-by-name.
I also explain how ‘lambda’ is one of those academic terms that mathematicians and the functional programming people like, but other people go ‘huh?’. They are even integrating ‘lambdas’ in MS Excel. You can imagine what spreadsheet users will make of that! I told them Bertrand Meyer had decided on the clearer term ‘agent’ in Eiffel (one of the best ALGOL successors).
ALGOL 60 is indeed still used very significantly as Burroughs ALGOL, which is a suite of system languages, ensuring good separation of concerns.
https://public.support.unisys.com/aseries/docs/ClearPath-MCP-18.0/86000098-516/index.html
https://public.support.unisys.com/aseries/docs/clearpath-mcp-17.0/pdf/86002003-407.pdf
https://public.support.unisys.com/aseries/docs/ClearPath-MCP-18.0/82057498-000/section-000024178.html
Indeed C got the idea of high-level system programming from Burroughs ALGOL which was doing this since 1961. C even got its #defines from Burroughs ALGOL (although Burroughs defines were much better, using # as a terminator not introducer). The idea of defines in Burroughs ALGOL came from a suggestion of Don Knuth. Macro processing was also a development of Christopher Strachey who designed CPL, the basis for C.
Why didn’t ALGOL become so widely used as COBOL, FORTRAN, or C? It is due to the fact that ALGOL was a starting point and ignited many streams of research, which splintered. You mentioned ALGOL-68, but there was also ALGOL-W (Wirth and Hoare), then Pascal. Also CPL (Christopher Strachey) and the simplified BCPL (Martin Richards) which formed most of the basis of B and C.
https://www.cl.cam.ac.uk/~mr10/strachey100.pdf
Then with Pascal, Wirth learnt from the experience and went on to Modula and then Oberon. Strachey indeed learnt from CPL and went on to further research the foundations of programming.
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.332.3161&rep=rep1&type=pdf
John Backus went on to FP:
http://worrydream.com/refs/Backus-CanProgrammingBeLiberated.pdf
Dahl and Nygaard developed Simula out of ALGOL, thus creating the OO explosion taken up by Alan Kay et al., in Smalltalk, and others like Bertrand Meyer in Eiffel, and most regrettably Bjarne Stroustrup in C++ (which still isn’t right, and probably never will be).
ALGOL parameters indeed got the default around the wrong way. They should have been by-value as default, not by-name or reference. This indeed would have averted John Carter’s problem. And that was the position of Pascal and later. Language designers learn from their mistakes and from the mistakes in ALGOL. It is regrettable C does not have that kind of honesty.
Thus most good languages have progressed and new languages invented. It seems we are stuck with the bad languages. In particular, C has many problems, but these have mainly never been fixed, addressed, or even admitted over the years. When one draws attention to the mistakes and deficiencies in C, one is attacked by C afficianados who believe that despite the glaring flaws and compromises of early 1970s and not matter what the improvement in programming practice, C must be a perfect language.
While ALGOL and its designers moved on, C and other such languages have failed to do so. C++ just bakes in the flaws of C and makes its own and introduces worse. This has done OO and programming in general a great disservice. The opportunity for OO to get programming on a good course has been negated by C++. Too many C and C++ people excuse the flaws in the languages saying “programming languages aren’t important, it is the processes around them”. This gives rise to auxiliary things like UML (also awful), and a fight between Waterfall and Agile, trying to ignore the elephant in the room of language design and deficiencies, and failing to address the language flaws, holes, and subtle traps (such as John Carter’s objection to call-by-name — although not having call-by-name until lambdas has been throwing out the baby with the bathwater).
“C is quirky, flawed, and an enormous success.”
— Dennis Ritchie
https://www.inspiringquotes.us/quotes/2Rki_bGM7zqTA
“Strive not to be a success, but rather to be of value.”
https://www.azquotes.com/quote/87317
Thus most other languages including ALGOL move on, and C has failed to do so, except as C++. I prefer the languages which have been of value, rather than those that have been a success. Thus ALGOL has sparked much good development, which has mainly died because of C and C++.
ALGOL has been of tremendous value, but not so much a success (except within Burroughs/Unisys, where it is now legacy, but at least a good one).
Lastly, I’m not sure what you mean by “Orthogonality of language use won out over the goto FUD.” Orthogonality is indeed a good quality to aspire to, since it stops those horrible little surprises which can be very expensive and difficult to fix when two incompatible language features are used together. ALGOL-68 wanted to address the remaining non-orthogonalities in ALGOL-60 (hence popularising the term).
Then what do you mean about goto FUD? The problems with goto and undisciplined programming are well known. The warnings about goto are not FUD, but well founded, as Dijkstra pointed out in his original ‘Goto Considered Harmful’ paper.
https://www.quora.com/Why-is-the-GOTO-statement-in-some-programming-languages-considered-bad/answer/Ian-Joyner-1
As for ‘supporting undefined behaviors Such as: “The effect, of a go to statement, outside a for statement, which refers to a label within the for statement, is undefined.”’
Well, ALGOL didn’t ‘support’ that. Undefined behaviours in languages are unacceptable, and being deliberately undefined as in C and C++, just nonsense. I’m fairly sure Burroughs Extended ALGOL would have rejected such gotos. But gotos are very rarely used in the entire Burroughs software suite.
@John Carter
Hi John, I have addressed your problem about ‘call-by-name’ in my response. The fix (in later languages) was to default to call-by-value, with call-by-name being deliberate and intentional on the part of the programmer. However, rejecting call-by-name would be throwing out the baby with the bathwater as lambdas are now proving.