[HN Gopher] Dijkstra's Crisis: The End of Algol and Beginning of...
___________________________________________________________________
Dijkstra's Crisis: The End of Algol and Beginning of Software
Engineering (2010) [pdf]
Author : ipnon
Score : 59 points
Date : 2026-03-09 07:49 UTC (4 days ago)
(HTM) web link (www.tomandmaria.com)
(TXT) w3m dump (www.tomandmaria.com)
| Rochus wrote:
| 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.
| shrubble wrote:
| 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."
| EvanAnderson wrote:
| Always worth pointing out what Alan Kay said about this quote
| on HN when it comes up:
| https://news.ycombinator.com/item?id=11796926
| aidenn0 wrote:
| Thanks for linking! His description of Dijkstra in that
| comment reminds me a lot of my few interactions with Doug
| Comer.
| csb6 wrote:
| 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.
| AnimalMuppet wrote:
| 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?
| thwarted wrote:
| 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.
| kelipso wrote:
| Yes, who would say structured programming is bad these
| days, though maybe it wasn't a popular sentiment at the
| time. Though I find this thread funny, "Dijktra was
| elitist, oh no, he did the gatekeeping, what horror,
| let's abandon structured programming and seeing
| programming as a discipline altogether".
| bsoles wrote:
| His article "On the cruelty of really teaching computing
| science" (https://www.cs.utexas.edu/~EWD/transcriptions/EWD10
| xx/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.".
| adrian_b wrote:
| 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.
| Rochus wrote:
| > ALGOL 68 was much better than the ALGOL W .. or any of the
| languages designed later by Wirth.
|
| In what respects particularly?
| adrian_b wrote:
| There are too many things for a short explanation.
|
| 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.
| nradov wrote:
| 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.
| jnpnj wrote:
| > 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 ;)
| random3 wrote:
| 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.
| nradov wrote:
| 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.
| random3 wrote:
| 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.
| nradov wrote:
| 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.
| random3 wrote:
| 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.
| AnimalMuppet wrote:
| 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).
| random3 wrote:
| Check out Urs Schreiber if you want to get over it
| pjm331 wrote:
| "Software people are not alone in facing complexity.
| Physics deals with terribly complex objects even at the
| "fundamental" particle level. The physicist labors on,
| however, in a firm faith that there are unifying
| principles to be found, whether in quarks or in unified
| field theories. Einstein repeatedly argued that there
| must be simplified explanations of nature, because God is
| not capricious or arbitrary.
|
| 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
| salawat wrote:
| >"There's no free lunch" - this is representative of the
| level of argument in software circles entirely. But WTF
| does that mean?
|
| You cannot have a thing without doing the work to build
| it. You don't get the better abstraction without
| implementing it first. Your proof in theory, is just
| that, until exercised, and the divergence from the ideal
| to the real world is finally realized. I can teach a
| programmer all manner of linguistic trickery to allow
| them to exploit all sorts of mathematical abuse of
| notation. None of that makes a cotton-picking, salt-
| licking bit of difference if at the end of the day, if
| your symbolic proof isn't translateable to a machine code
| that runs and maps successfully onto the operational
| space of an implementation of a computing device. If you
| give a program written in the form of a Shakespearean
| sonnet (an example of a focus on radical novelty in
| encoding a program without regard to analogy); say; I
| still need a bloody compiler that'll turn that into
| something that is capable of running within the
| constraints of the machine, and the other primitives to
| make it work. That's TANSTAAFL. You break from what
| exists; you still have to reroot and establish a parallel
| basis of operation that covers the primitive operations
| you're familiar with. Djikstra might be right. There's
| something liberating to staying in the realm of the
| formal and mathematical. His detractor's were also right.
| He is so damn far above everyone else, that everybody in
| the room has trouble understanding just what it is he's
| going on about. At the end of the day, teach what the
| greatest number of the people there can firmly mentally
| grip, and pass that on. The geniuses like Djikstra will
| quickly outgrow it, and excel. They don't need the help.
| Everyone else on the other hand, does. I wouldn't be
| opposed, to trying Djikstra's approach myself. Shattering
| my current understanding of the practice of programming
| and working more from a formal methods POV. That comes
| after a career which has been fruitful, and was rooted in
| the old way which worked quite well for many others
| educated at the same time I was. I already know I can do
| it. His method just changes the emphasis. Though I will
| note with alarm, his reticence to test is disturbing. If
| he does assume everything is proofable from the get go,
| then I suppose you don't need tests; but that's hardly
| the way anything in the world actually bloody works.
| That's Math in a vacuum, with spherical cows. Not writing
| code then realizing "Shit, the processor in the machine
| I'm writing for doesn't support that primitive, or has a
| glitchy implementation thereof".
|
| Software engineering isn't programming for people who
| can't; it's a set of practices and know-how to navigate a
| niche field that are battle hardened, and tested through
| time to actually guarantee some semblance of a chance of
| success in a field shaped by such fast development, the
| logic of 6 months ago seems antiquated. For that time
| with Moore's Law in full swing, yeah. Radical novelty
| might have been justifiable; but ultimately didn't push
| past the test of time. It can be as clever a hack as you
| can imagine, but if no one else can follow it... You
| haven't condensed it to a teachable form.
___________________________________________________________________
(page generated 2026-03-13 23:01 UTC)