My own incomplete opionion is that the net effect is that we ended up writing orderd of magnitude more code than necessary to solve the problems at hand. It's the equivalent of doing the computations manually instead of using a calculator. This has led to an industry that has served us well, but strictly speaking it was never necessary and much more could have been achieved with a fraction of the resources.

Moreover, even the report about ALGOL 68 was not bad as a tool for a compiler designer who must search through it which is the correct syntax for various language features. The ALGOL 68 report even contained some subtle humor.

However where ALGOL 68 was a complete failure was that Van Wijngaarden and his collaborators did not publish any other document about ALGOL 68, except the Report.

The Report was completely unsuitable as the first document used by someone who wanted to know what ALGOL 68 is and what it does.

The only way in which ALGOL 68 could have succeeded as a language would have been if Van Wijngaarden would have published at least 3 documents to be read before reading the Report: a tutorial presenting programming examples of using ALGOL 68, a rationale for the design choices of the language (like the designers of the Ada language have published at its introduction) and a document explaining how the Report with the formal specification of the language has to be read.

Without these preliminary documents, the Report about ALGOL 68 looked too alien and it required too much effort to reverse engineer how it is supposed to be understood that even people with the experience of Dijkstra did not bother to make the effort to understand it, so they never knew whether there actually is something valuable in the report or not.

Many years ago, when I have seen for the first time the ALGOL 68 Report, my first thought was also that this must be some kind of useless garbage, and I did not read it. Only years later I tried again and that time I read most of it, so I could see that actually many important programming language features were described there for the first time, and some of them were actually better in ALGOL 68 than in later languages.

I really cannot understand what was in the mind of Van Wijngaarden, how could he believe that publishing this report alone, without accompanying it with a set of explanatory documents, would be enough for other people to learn what ALGOL 68 is. His reputation has certainly suffered after the publication of this report, so whichever was his reason to not write and publish more at that time, it was a wrong decision for his career.

"I don't know how many of you have ever met Dijkstra, but you probably know that arrogance in computer science is measured in nano-Dijkstras."

> A number of these phenomena have been bundled under the name "Software Engineering". As economics is known as "The Miserable Science", software engineering should be known as "The Doomed Discipline", doomed because it cannot even approach its goal since its goal is self-contradictory. Software engineering, of course, presents itself as another worthy cause, but that is eyewash: if you carefully read its literature and analyse what its devotees actually do, you will discover that software engineering has accepted as its charter "How to program if you cannot.".

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

In what respects particularly?

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.

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.

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.

Do you feel like software transcends pyhsics, mathematics and logics? Because that's what the statement translates to.

The only reason it's impossible, is because nobody tries, because trying to do so would interfer with the deliverables of next sprint. The software industry has painted itself into a corner.

No such faith comforts the software engineer. Much of the complexity he must master is arbitrary complexity, forced without rhyme or reason by the many human institutions and systems to which his interfaces must conform. These differ from interface to interface, and from time to time, not because of necessity but only because they were designed by different people, rather than by God."

- Fred Brooks, No Silver Bullet