Dijkstra's rebellion against Algol 68 was deeply ironic. While he drafted the minority report condemning Algol 68 as an "obsolete" tool, his goal was not to make programming easier for everyday developers; instead he used the "software crisis" to advocate for replacing vast teams of average, working-class programmers with an elite corps of "mathematical engineers" modeled on himself. While Wirth and Hoare focused on building practical engineering tools, Dijkstra championed a highly theoretical, ivory-tower approach to programming based on strict mathematical principles and structured logic. Interestingly, both Wijngaarden (the primary architect of the highly complex "mathematical" and heavily criticized Algol 68 specification) and Dijkstra were Dutch.
> 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.".
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.
not too far from what Tony Hoare said about ALGOL 60 ;)
In what respects particularly?
"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."
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.
There's an irony about the design of ALGOL 68. It was denounced at the time as being too big a language, with too many experimental features. In fact, the language in the Report is unimplementable, primarily because the lexical syntax is fanciful (there's an actual difference between the roman period and the italic period) and also abstract (so no two implementations actually have the same lexical syntax). I was on the periphery of an ALGOL 68 implementation project that foundered because the goal was to implement every conceivable edge case, include those that could never occur in practice, e.g., x[i] := x[...50 pages of code...] Yet very reasonable subsets (including ALGOL-68R and FLACC) were built. As for the language breadth, arguably C# is much broader, and I haven't heard anyone claim that it is a failure.
As for the Report...there was a time when I understood it cover to cover. But Lindsey and van der Meulen's Informal Introduction presented the whole language at a level understandable to anyone who understood ALGOL 60. van Wijngaarden did the language a terrible disservice when he forced (that is the correct word, I believe) the use of two-level grammars in order to ensure type correctness. Had the Report never existed, the language would have had much more traction.
The irony? Apart from the grossly-overengineered “transput” library—much better adapted to a unit-record and line printer world than our modern world—the one actual experimental feature in the language was the par clause, which provided parallel execution, and relied on semaphores for synchronization. Dijkstra's semaphores.
Excerpts:
What, for Dijkstra, was the crisis? I believe it was the separation of practice from theory in the development of commercial systems software. Recall the background shared by many of the most distinguishing contributors to the Nato conference, such as Dijkstra, Hoare, Perlis, Naur, and Wirth. They were exceptionally gifted men, many with strong scientific backgrounds, who in the early- and mid- 1960s had produced effective, elegant and reliable pieces of systems software with small teams and tiny budgets while working in research environments or for marginal computer firms. They were not by temperament successful corporate managers or project management specialists. So their instinct was to recoil as word spread of out-of-control industrial development efforts in which millions were being spend to produce unreliable, bloated, and incomplete operating systems and compilers ... Instead their faith was that with the application of suitably rigorous and mathematical methods a small team could produce high quality systems software without the need for massive teams of programmers and elaborate bureaucratic controls.
Near the end of his life, Dijkstra wrote that
"The ALGOL implementation was one of my proudest achievements. Its major significance was that it was done in 8 months at the investment of less than 3 man-years. The rumour was that IBM's FORTRAN implementation had taken 300 man-years and thus had been a project in size way beyond what a university could ever hope to undertake. By requiring only 1 % of that labour, our compiler returned language implementation to the academic world, and that was its political significance".
Yet his single biggest complaint, and one underlying many of the others, was against the idea that computer scientists must adjust their expectations to a world in which most programmers are intellectually mediocre and theory-averse. This is why he called himself a “humble programmer” in his Turing award speech, rather than, as his colleagues might, an arrogant (albeit insecure) academic computer scientist. Trained as a physicist he believed that the proper model for programming came from “mathematical engineering,” a concept he claimed was well understood in the Netherlands but which thoroughly confused his American colleagues. By seizing the mantle of programmer, despite his increasingly deep immersion in the world of mathematical theory and formal methods, Dijkstra could insist that he had not left programming behind. If actual programmers failed to grasp the importance of his new work then it was they who were betraying the true essence of programming.
Dijkstra gave a particularly clear statement of this in 1977, in an open letter circulated to fellow members of Working Group 2.3. According to Dijkstra, in the late 1960s it “became abundantly clear that we did not know how to program well enough.” As a result “people concerned with Programming Methodology,” by which he presumably means him and his fellow working group members, discovered that programming was “a tough engineering discipline with a strong mathematical flavor.” However this inarguable conclusion was sometimes ignored, “because of the unattractiveness of its implications, such as,”
(1) good programming is probably beyond the intellectual abilities of today's 'average programmer’
(2) to do, hic et nunc, the job well enough with today's army of practitioners, many of whom have been lured into a profession well beyond their intellectual abilities, is an insoluble problem
(3) our only hope is that, by revealing the intellectual contents of programming, we will make the subject attractive to the type of students it deserves, so that a next generation of better qualified programmers may gradually replace the current one.
According to Dijkstra, only “political or emotional reasons” could explain disagreement with these “technical” observations. He conceded that they were “unattractive” and had “severe” social implications and no quick solutions. Clearly it would not be easy to replace almost the entire programming workforce. But he dreamed of a scientific revolution, in which programming would win recognition as a mathematical discipline and the incompetent hordes currently messing things up would be swept away and replaced by an elite corps of scientists versed in new and more formal methods of software development.
PS: With AI tools becoming the norm in programming today, things are going to become exponentially worse if "the average programmers" do not study and use formal mathematical methods for code generation and verification.
