Dijkstra's Crisis: The End of Algol and Beginning of Software Engineering (2010) [pdf]

Why are the abstractions leaky? Are all abstractions leaky? Why - we simply accept the situation without spending any real effort.

"There's no free lunch" - this is representative of the level of argument in software circles entirely. But WTF does that mean? If the lunch is not free, how cheap or expensive can it get and why?

This is why, as engineers, we tend to brush off the Dijkstras as arrogant, while at the same time ignoring both our arrogance and ignorance.

You're simply wrong to claim that we accept the situation without spending any real effort. In reality the more experienced developers who build abstraction layers tend to spend a lot of time trying to prevent leaks, but they can't have perfect foresight to predict what capabilities others will need. Software abstractions often last through multiple major generations of hardware technology with wildly different capabilities: you can't prevent those changes from leaking through to higher levels and it would be foolhardy to even try.

not too far from what Tony Hoare said about ALGOL 60 ;)

A nice feature of ALGOL 68 that was new at that time was the fully bracketed syntax (like later in the Ada language) with different kinds of brackets for different purposes, i.e. not just one "begin" and "end" pair (or "{" and "}" pair). Having different kinds of brackets for loops, conditional statements and blocks greatly improves the readability of a program, while avoiding the verbosity of commenting the brackets to achieve a similar effect, like it would be needed in languages like Pascal or C. In languages with fully bracketed syntax, the number of brackets used in a program is frequently much smaller than the number of parentheses and braces that must be used in C, where the various kinds of statements do not include braces in their definition, but in practice you must almost always use compound statements enclosed in braces, instead of simple statements. This leads to much more parentheses and braces than are needed in languages with more uniform syntax, like ALGOL 68. E.g. ALGOL 68 "if A then B else C fi" vs. C "if (A ) {B;} else {C;}". I find the first much more readable than the second, which is full of superfluous symbols. Pascal was not much better than C, for the same reason of defining the program structures based on simple statements, when in reality almost always compound sentences are needed, which add redundant instruction brackets in comparison with ALGOL 68.

Compared with the languages of Wirth, ALGOL 68 had more methods for creating data types, e.g. it had tagged unions that worked correctly, not like the crippled and buggy variant records of Pascal. Moreover, the various kinds of defining types could be used in an orthogonal way, which was not the case in the Wirth languages. Also, ALGOL 68 did not have defects like that of the array type from Pascal, where the size of the array was a part of the type and there was no way to declare arrays whose sizes are known only at run time.

ALGOL 68 could allocate variables dynamically, either in a stack or in a heap. This feature had appeared for the first time in the language IBM PL/I, but while in PL/I the heap variables had to be managed manually, with allocate and free, the ancestors of C malloc and free, in ALGOL 68 the heap was managed with a garbage collector like in LISP.

ALGOL 68 had a FOR and WHILE loop syntax that was equivalent with that of PL/I, and both of them were significantly improved over the loop syntax of ALGOL 60 and over the loop syntaxes used in ALGOL W or Pascal or any other of the Wirth languages. ALGOL 68 and PL/I can express loops that are more general than those that can be written in Pascal, Modula or any other Wirth language, but this is accomplished without increasing verbosity, because all elements of a loop specification are optional, so they can be omitted when not needed (this is possible because distinct keywords are used as separators, instead of ambiguous symbols like semicolons or parentheses, so whenever a part of the loop specification is omitted that does not confuse the parser). An example of an ALGOL 68 loop: "for I from A by B to C while D do E od", where any of the parameters together with the keyword that precedes it may be omitted when it has the default value. The WHILE and FOR conditions are combined correctly, so such a loop may express e.g. a search, which can be terminated either when the desired value is found or when all the data structure has been scanned.

Later, the C language introduced a syntax for the FOR loop that allows the writing of some very complex actions in the loop header, more complex than those that can be described in the PL/I or ALGOL 68 loop syntax. However, I consider that the C FOR was a mistake. While in rare cases its generality allows a more elegant writing of some unusual loops, for the 99.999% of the loops that are simple the C FOR syntax forces the programmer to write superfluous boilerplate. This can be simplified at writing if you configure your editor to insert complete FOR templates whenever needed, but the verbosity of the C FOR still hinders program reading in comparison with the simpler syntax of ALGOL 68.

This has not existed in ALGOL 68 at the beginning, but a dialect of ALGOL 68 was one of the first languages that has implemented a kind of FOR EACH loop, which is preferable for the large fraction of the loops that can be expressed in this way (the first language with a FOR EACH was LISP, where several kinds of MAP forms were equivalent with a FOR EACH iteration). Nowadays, in C++ one can avoid most classic C FOR loops by replacing them with simpler FOR EACH loops, but their syntax is much less clean than in languages like ALGOL 68.

There are many other features, one would have to write a full-length article to describe them. There are some ALGOL 68 features that have been inherited by the C language, e.g. the operation-and-assignment operators.