Intersting. The author of the attached document is Dr. Thomas Haigh, a prominent academic historian specializing in the history of computing. The document challenges the conventional historical narrative surrounding the birth of software engineering. It argues that the widely accepted origin story centering on the 1968 NATO Software Engineering Conference and the "software crisis" was actually a narrative constructed by a group of academic researchers to promote their vision of programming as a mathematical discipline.
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.
Not sure if I agree with his conclusion that Dijkstra believed all programming should be done by an "elite corps" of programmers. He believed (rightly or wrongly) that undergraduate students could be taught his mathematical methods of programming, and that formal methods could make programming simpler and more manageable. Claiming he was against "working-class" programmers seems silly; anyone employed as a programmer will work for a living and so would be working-class.
His article "On the cruelty of really teaching computing science" (https://www.cs.utexas.edu/~EWD/transcriptions/EWD10xx/EWD103...) really resonated with me in the past, albeit it might be enforcing the assessment of the parent post regarding his more elitist approach to software development. He says:
> 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.".
All right, he believed that all programming should be done by his approach, or one highly similar. He could train undergrads, but anyone who wasn't trained his way shouldn't be programming. Is that a fair statement?
This is such a common position in just about every professional industry, codified legally or as personal belief, that it barely qualifies to be called out as unique to Dijkstra.
IDK what Dijkstra believed in terms of how programmers should have looked like, bu the did seem to have a sense (and taste) of a direction of programming that was lost within practicing software engineering and their prefered PLs.
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.
While there is certainly some amount of unnecessary junk code out there, your claim that it could be reduced by an order of magnitude isn't even close to correct. In general the only way to write less code is to use higher level abstractions. The problem, of course, is that those abstractions are always leaky and using them tends to make certain required features too slow or even impossible to build at all. There is no free lunch.
as programmers we like to use all this jargon like "leaky abstraction", but never bothered to understsand it beyond the PL paradigms we use.
There's no formal definition and simply makes them good terms to abuse, and throw in conversations to make our points.
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 leaky abstraction is like obscenity: I know it when I see it. It's impossible to define the concept in a rigorous way, and yet it impacts everything that we do.
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.
I understand your position and I think it's the norm. Yet I find it difficult to comprehend how it's not self-evidently absurd.
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.
Physics is full of leaky abstractions. Solid? Leaky abstraction (melting). Ideal gas? Leaky abstraction (van der Walls). Molecule? Leaky abstraction (chemical reactions). Atom? Leaky abstraction (ionization, fusion, fission, alpha and beta decay). Proton? Leaky abstraction (sometimes you have to care about the quarks).
Dijkstra was wrong about ALGOL 68. ALGOL 68 was much better than the ALGOL W proposed by Wirth, or than its successor, Pascal, or than any of the languages designed later by Wirth.
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.
ALGOL 68 failed not only due to bad documentation but also because it was simply too complex to fully implement in a compiler given the limited hardware resources and project management methodologies available at the time. The few organizations that did try to write compilers each ended up implementing a different limited subset of the language so it was impossible to share much with a broader community.
Intersting. The author of the attached document is Dr. Thomas Haigh, a prominent academic historian specializing in the history of computing. The document challenges the conventional historical narrative surrounding the birth of software engineering. It argues that the widely accepted origin story centering on the 1968 NATO Software Engineering Conference and the "software crisis" was actually a narrative constructed by a group of academic researchers to promote their vision of programming as a mathematical discipline.
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.
Not sure if I agree with his conclusion that Dijkstra believed all programming should be done by an "elite corps" of programmers. He believed (rightly or wrongly) that undergraduate students could be taught his mathematical methods of programming, and that formal methods could make programming simpler and more manageable. Claiming he was against "working-class" programmers seems silly; anyone employed as a programmer will work for a living and so would be working-class.
His article "On the cruelty of really teaching computing science" (https://www.cs.utexas.edu/~EWD/transcriptions/EWD10xx/EWD103...) really resonated with me in the past, albeit it might be enforcing the assessment of the parent post regarding his more elitist approach to software development. He says:
> 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.".
All right, he believed that all programming should be done by his approach, or one highly similar. He could train undergrads, but anyone who wasn't trained his way shouldn't be programming. Is that a fair statement?
This is such a common position in just about every professional industry, codified legally or as personal belief, that it barely qualifies to be called out as unique to Dijkstra.
Alan Kay famously said:
"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."
Always worth pointing out what Alan Kay said about this quote on HN when it comes up: https://news.ycombinator.com/item?id=11796926
Thanks for linking! His description of Dijkstra in that comment reminds me a lot of my few interactions with Doug Comer.
IDK what Dijkstra believed in terms of how programmers should have looked like, bu the did seem to have a sense (and taste) of a direction of programming that was lost within practicing software engineering and their prefered PLs.
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.
While there is certainly some amount of unnecessary junk code out there, your claim that it could be reduced by an order of magnitude isn't even close to correct. In general the only way to write less code is to use higher level abstractions. The problem, of course, is that those abstractions are always leaky and using them tends to make certain required features too slow or even impossible to build at all. There is no free lunch.
as programmers we like to use all this jargon like "leaky abstraction", but never bothered to understsand it beyond the PL paradigms we use. There's no formal definition and simply makes them good terms to abuse, and throw in conversations to make our points.
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 leaky abstraction is like obscenity: I know it when I see it. It's impossible to define the concept in a rigorous way, and yet it impacts everything that we do.
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.
I understand your position and I think it's the norm. Yet I find it difficult to comprehend how it's not self-evidently absurd.
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.
Physics is full of leaky abstractions. Solid? Leaky abstraction (melting). Ideal gas? Leaky abstraction (van der Walls). Molecule? Leaky abstraction (chemical reactions). Atom? Leaky abstraction (ionization, fusion, fission, alpha and beta decay). Proton? Leaky abstraction (sometimes you have to care about the quarks).
Dijkstra was wrong about ALGOL 68. ALGOL 68 was much better than the ALGOL W proposed by Wirth, or than its successor, Pascal, or than any of the languages designed later by Wirth.
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.
ALGOL 68 failed not only due to bad documentation but also because it was simply too complex to fully implement in a compiler given the limited hardware resources and project management methodologies available at the time. The few organizations that did try to write compilers each ended up implementing a different limited subset of the language so it was impossible to share much with a broader community.
> and some of them were actually better in ALGOL 68 than in later languages
not too far from what Tony Hoare said about ALGOL 60 ;)
> ALGOL 68 was much better than the ALGOL W .. or any of the languages designed later by Wirth.
In what respects particularly?