"ALGOL 60 at 60: The greatest computer language you've never used"

It’s just possible there are some here for whom the headline doesn’t apply, but it’s an interesting article in any case:

Here’s a good quote on the much-maligned successor:

The last edition of The ALGOL Bulletin was published in 1988, with its editor noting: “ALGOL 68 as a language is very stable. It is used and loved by those who understand its benefits, and ignored (or misquoted) by the rest.”

On the influence:

ALGOL 60 also heavily influenced the Combined Programming Language (CPL), developed in the 1960s but not implemented until the following decade. CPL in turn led to Basic CPL (BCPL), from which B descended. The B language was further developed to become C.

There’s a video within of the Elliott 803 at TNMoC running its Algol 2 compiler from paper tape:

Peter Naur wrote a retrospective “Paper: the European side of the last phase of the development of Algol 60”


I have written just one Algol program - oddly enough on an Elliot 903 - which I had access to in the summer of 1980 when I was on a job experience project while at uni.

And at the risk of straying OT a little…

The job was in the Clinical Chemistry department at the Edinburgh royal Infirmary and '903 was the back computer to the ICL mainframe to process blood analysis tapes - the code I was updating was in a sort of assembler (called SIR) but I had time to “play” with the '903 and found the Algol tapes, so wrote a trivial “Hello, world” program in Algol just because it was there.

I’ve also met the venerable Peter Onion at TNMoC - vastly knowledgeable on the subject of both Algol and the Elliot 803 there - He even has a really nice emulator of the '803 that runs well on a Raspberry Pi.




Excellent - I’ve spent a couple of hours at least chatting to Peter at TNMoC, and saw an earlier version of his emulator. I see this on the page you linked, skeuomorphic might be the word:

As the article mentions the lack of commonly defined input/output functions (well, the Report mentions at least READ, PRINT, TYPE, WRITE), it may be worth noting that Algol wasn’t just a programming language, it was at first a problem description language, which could also be used as a programming language thanks to particular hardware representations of the language. E.g., when used as an abstract language, Greek letters may be used for identifiers, while a hardware representation may choose to put keywords in single quotes (as the PDP-8 implementation did). The relationship of a hardware representation to the abstract language isn’t much unlike the relation of APL as a programming language to the original mathematical notation. So for Algol as an abstract language, the lack of a rigorous definition of a standard I/O library may be forgivable, while it’s certainly a problem for the programming language.

Personal note: Algol 60 was actually my first programming language, but I only programmed on paper with it, with no compiler accessible to me. I have always been impressed with the aesthetics of an Algol program.

P.S.: A copy of the Revised Report on the Algorithmic Language Algol 60 is problably the oldest web page by me still around: Revised Report on the Algorithmic Language Algol 60

1 Like

My first real computer was the university’s Burroughs B6700 so I did some Algol programming. Since Burroughs gave its clients all the source code, the group I worked with adapted their extended Algol compiler to generate Motorola 6800 assembly. They had a homebrew 6800 machine that looked like a terminal to the B6700 and multiplexed a bunch of odd peripherals. So I would build a specific adapter card (for the two TV Typewriters or for the optical card reader for student exams, for example) and then write the drivers in the patched Algol.


There’s another take on this anniversary on The Shape of Code blog:
Happy 60th birthday: Algol 60

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…

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).

1 Like

Thanks for the links, esp. “ALGOL 60 implementation”!

I worked with ALGOL 60 very briefly, on a CDC-3300, but then I discovered SIMULA-67, which is very much a superset of ALGOL 60, but with capabilities that almost seemed magical in the late 1970s.


Bonus track… :wink:

1 Like

I’m a big fan of those Prof. Brailsford videos, but he may be a bit unfair here for the sake of an argument. We have to remind ourselves that Algol wasn’t just the first structured language, but also the first rigorously defined one. So, what’s happening here? A block, in this case the main block, may have definitions, here a procedure and two variables. (No, the variables aren’t starting the main program, they are at the same level as the procedure definition.) The rest is a matter of strict consistency: Where there is a single statement, there can be a block (and vice versa). Only exception is that the entire program is wrapped into a block, as well. Since, probably we’ll need some definitions (which were later moved out of the block by languages like Pascal for similar reasons as the ones provided here).

Mind that the statement block equivalence is still true for almost all languages regarding loops and conditions. (Arguably, these contribute to even lesser readable parts in the Ackermann program.)

The lesson learned is that consistency and strictness of definition isn’t all. Forcing blocks for functions and procedures (by this making them some special mini programs of their own) may be worth it, even, if this introduces some inconsistency into your syntax. However, at the time, going for consistency was the reasonable thing to do.

P.S.: The general idea behind the assignment to function name was that your procedure could do other things as well. While a return statement ends the control flow and exits the the function, this isn’t necessarily the case with the assignment. Here, the procedure is just the declaration of a getter mechanism. It is more flexible and consistent (how does a break statement transport a value, like with return?), but, again, we found we could do better without it.

If he didn’t like the lack of begin and end in the function definition, there was nothing stopping him from adding them.

I found it odd that he kept insisting on calling the assignment to the function name a “pseudo assignment”. You can certainly have implementations where that is the case but for most reasonable calling conventions it can be a real assignment. Imagine that you always put the return value in r1 in some RISC processor. Then the compiler will just translate that into code that saves the value in r1.

Notably, if I’m recalling this right, Prof. Brailsford had a rather interesting and insightful footnote in a previous video on how recursion was smuggled into Algol. I guess, the example was much taylored for the purpose, and the interpretation is a bit one sided, as well. (E.g., you could have used the same example for how much more efficient and stringent Algol had been as compared to C.) Probably not the most of inspired videos. To me, the overall feel was, “So you want me to say some about ALGOL 60 on a sunny day like this?”

Fun fact: Having originally learned languages like Algol or Pascal, I first found C-like syntax rather obfuscated in comparison. Readability and clearity is very much a question of culture and what we are accustomed to.

Also, regarding function one-liners: what about arrow functions?

Regarding how some things were much more versatile in ALGOL 60, but also a bit underdefined in terms of implementation, compare this section from the Revised Report on procedures:

5.4.6. Code as procedure body. It is understood that the procedure body may be expressed in non-Algol language. Since it is intended that the use of this feature should be entirely a question of hardware representation, no further rules concerning this code language can be given within the reference language.

From a stand point of a fully defined language, this may be quite a gapping omission, however, from the stand point of a high-level definition language, which happened to be a programming language, as well, it may have been wise to leave this (and how this may be encapsulated) to the particular implementation. (Especially, given the variety of hardware available at the time and what external mechanisms may have been available or not.)

I also started with Algol/ESPOL, Pascal and was learning Ada when I ran across C. I really enjoyed the different syntax though still like the old style in VHDL, but not so much in Oberon.

A friend, on the other hand, started all his C programs with

#define BEGIN {
#define END }
#define AND &&
#define OR ||

and so on. The rest of his C program was in Pascal syntax. I thought it was far less readable. But when I see new languages copy C and claim as a feature their “intuitive syntax” I have to laugh. They should have used the word “familiar” instead.


For an example to the contrary, some time ago I was musing about having a higher level language for writing Web Assembly code without losing any of the more assembly-like directness. As it happens, there’s already PL/M (the language Gary Kildall used to implement CP/M), which has all the desirable features – no need to reinvent the wheel. However, no one, including myself, would buy an ALGOL-like syntax nowadays. Therefore, it seemed reasonable to introduce C-style brackets, etc, as an alternative syntax. Just the other way round as in your example. tempora, mores, etc.! It’s all about familiarity. (BTW, nothing has come of this in terms of an actual project yet.)

I once worked in a team whose product was an in-house CAD system, written in Pascal. But it was said of one of the team that he wrote in Fortran. I’ve certainly heard the phrase ‘you can write Fortran in any language.’

Writing Fortran in a new $LANGUAGE is a great way to learn the language. “Fortran” is pretty simple. Simple Fortran is simple. Things like COMMON blocks and COMPLEX numbers don’t move well, but the rest does. It’s a solid “lowest common denominator” language and has the significant broad concepts (variables, expressions, iteration, I/O – these will take you far).

Some languages are more accommodating than others, but nevertheless it gives you a leg up in adopting that language.

Simply, when approaching a new language, just try to do a 1:1 translation of Code You Know in $YOUR_LANGUAGE, and convert it in to $LANGUAGE. In the end, you should have something that works, that translates what you knew in the old language in to constructs in the new language.

What you don’t have, in the end, is an idiomatic version of your code. But that’s OK. Because now you can hit the same code again, but this time from a point of view of adding $LANGUAGE idioms and constructs in to your “working code”.

There’s still hurdles not doubt. Especially some of the modern functional languages etc that don’t look at all like what you’re used to. But when you’re “uplifting” something from a less expressive language to a more expressive language, then, ideally, you should be able to more or less get a pretty much straigh across conversion.

I liken this experience to what I had learning Lisp and Scheme. These languages always flumoxed me, reading them I would see concepts that were simply opaque to me, mostly because of the vocabulary used. Everyone loves LAMBDA, CDR, CAR, CADR.

But then I ran across a book “Simply Scheme”.

Simply Scheme used it’s own vocabulary early on. Its skipped the opaque, meaningless words. The word LAMBDA actually has a lot of history and weight behind it, and carries implications with it. But if you don’t know it history, at a glance, you’re pretty much out of luck.

Acting as a Rosetta Stone of sort, Simply Scheme jumped over that problem. Once I essentially learned “Lambda” meant “function”, it was an AHA moment and I could then proceed to write “Fortran in Scheme/Lisp”.

Much akin to “make it work, then make it fast” you can apply “make it work, then make it idiomatic”.

The original Bourne shell by Steve Bourne was famously written in “Bournegol”, which was this plus some other, similar constructions. (Its source can be browsed on TUHS.) It contains such gems as this (a random selection from some quick browsing):

LOCAL TREPTR	list(flg)
	REG INT		b;

	r = term(flg);
	WHILE r ANDF ((b=(wdval==ANDFSYM)) ORF wdval==ORFSYM)
	DO	r = makelist((b ? TAND : TORF), r, term(NLFLG));

It also, as discussed in the Bournegol thread linked above, uses some creative abuses of SIGSEGV to manage its memory handling, which reportedly turned out to be problematic in some Unix ports.

Remeber this is the late 1950’s. The often the only addressing mode was direct addressing. You had arguments over open and closed subroutines. IBM and the 7 dwarves (USA) were the only computers you could get unless you built your own. I still have not figured just what a Algol routine does, but it reflects the thinking of that era.
Here the history of Why it was done that way, is very needed lesson.

Interestingly, I just read the term “open subroutine” last night. The strange thing is, it is in a book from the mid-eighties! The book is The Digital Way: MACRO-11 Assembly Language Programming by James F. Peters. It was published in 1985, by which point I would have expected the word “macro” to have completely replaced “open subroutine” in any normal use — and particular when using MACRO-11! (All in all, it is not a terribly good book; it appears to be the classic sort of textbook which is really just a collection of course notes from some specific course, bound up and sold mostly to the students of a particular college where that course is taught. It’s not horrible, but I don’t think I’d bother to buy it again.)