It is quite astonishing. In EWD 139 – written in the first half of the 1960s – Dijkstra argues why their to-be build Dutch computer the EL (Electologica) X8 should no longer be equipped with a punch card reader. Looking back, for at least for twenty more years after this article (IBM) computers were still being equipped with punch card readers.
This is the control room of the Grande Dixence project in the vicinity of Zermatt, Switzerland. The complex problem of managing this large distributed hydropower system was tackled by deploying an Electrologica X8 computer system. Photograph copyright Mr. J.A. Th. M. van Berckel.
Not only is Dijkstra very clear with his arguments, but he is so much opposed to the punch card that finds that having to write them down he finds, very Dijkstra-ish, a test of his decency. His arguments are the following.
The punch card technology has become obsolete. It is simply not needed anymore, there is paper tape now (this is the time before terminals and time-sharing).
The way you must use punch cards, the “style”, leads to local solutions for reliability (parity checks) instead of structural redundancy solutions over the entire document.
The limitation of 80 characters leads to technical “ad hoc” conventions and constraints, and limits the ability to improve the readability of programs.
Finally, Dijkstra argues that a single card does not have information value. You need the whole stack, on the right order. Which makes punch cards very impractical to use.
Dijkstra concludes the article that is so much a Dijkstra paragraph, that I can not leave it out.
“Hier wil ik het bij laten. Als mensen mij komen vertellen, dat zij met recht van ponskaarten gebruik gemaakt hebben, dan verandert die mededeling minder aan mijn opinie over ponskaarten, dan over de man.Ik concludeer dan, dat deze man voldoende inventief of ordelijk geweest is om van een in wezen ongezond middel gezond gebruik te maken. Als pleidooi voor het medium – ik kan niet anders – is zo’n mededeling zonder enig effect.”
In my imperfect english:
“I will leave it with that. If people come tell me that they have rightfully used punch cards, than that statement changes less in my opinion about punch cards, than about the man. I conclude then, that the man has been sufficiently inventive or orderly to use an essentially unhealthy tool in a healthy manner. As a appeal for the medium – I can not do other – such a statement is without any effect.”
In EWD 108 and EWD 116 Dijkstra describes the banker’s algoritm to prevent a so-called deadly embrace. This algoritm manages different scarce resources in such a manner that all in need for one or more of the managed resources, are guaranteed to get their hands on the resource at some point in time.
Of course, in computer science, a computer – it’s operating system – manages a number of resources that are required by the processes running on the computer. And how many resources each process needs is not known beforehand (and often dynamically determined). The analogy used in the paper is that of a banker lending money to clients, with the complicating constraint that clients do not know beforehand exactly how much money they will need. So they can lend more funds later on.
The situation could occur that the banker has only left an x amount to lend out, and a client John comes with a request for an additional amount larger than x. The banker can only hope that one of the other clients will soon finish their business and return their money. Only then can the banker help John. If however none of the other clients however can finish their business without coming to the banker for an additional lending, the banker is in deep trouble. His clients are waiting for eachother to finish their business, but to finish the business they all need some more money which they all hold themselves. A deadly embrace – “dodelijke omarming”.
Paper EWD 108 is a first exploration of the algorithm. The core of the algorithm is the “trick” that the sum of the amount lended + the maximum amount needed of the last lender accepted is never larger than the amount of money the banker has available. As such the banker can always guarantee that he will get the money back because the last lender can always be satisfied. So the last lender is a sort of clinet of last resort. She can always guarantee return to a safe state is possible. An because for that state the algorithm also guarantee (inductively) that: “the sum of the amount lended + the maximum amount needed of the last lender accepted is never larger than the amount of money the banker has available”. (All my words.)
EWD 108 describes a small banker’s algorithm in pseudocode. The algorithm is somewhat clumsily written, and (because it )holds a goto (!) (goto consideren harmful). In EWD 116 the algorithm is refined, and no longer presented in pseudocode.The algorithm EWD 108 requires the claims for money to be sorted, the algorithm in EWD116 has removes this constraint.
Also in EDW 116 Dijkstra make a remark about different type of claims (in banker’s term, different currencies, for example). Apparently someone has made remarks that there may be different types of resources that need to be managed by the operating system – or Dijkstra himself thought it necessary to add this nuance. Dijkstra writes the algorithm is only applicable for a single type of resource (currency).
From a technical perspective the paper is interesting from an algorithmic perspective, and a story-telling perspective – it illustrates Dijkstra great use of metaphors from the mundane world to explain complex problems.
Also from a historical computing perspective the paper is remarkable. Dijkstra totally discards the possibility of pre-emptive scheduling – that is: have the banker tell one of his clients to pause his business until other clients have returned their money. In not even very modern computing this is very common: processes can be “pre-emptively” put to rest to make sure other processes can progress. Apparently at the time of writing, which we do not know for sure (both EWD’s are not dated; somewhere before 1964?) pre-emptive scheduling was to be invented (or Dijkstra would have been aware for sure).
In 1961, Edsger Dijkstra wrote EWD 68, a short but powerful critique of the idea of using natural language for computer programming. His objections are still relevant today, especially in discussions about AI and “natural” interfaces.
What is EWD68 about?
In EDW68 Dijkstra expresses his concerns about a project reported by researcher H.J. Gawlik to create a compiler based on a combination of mathematical notation and plain English. Dijkstra’s concern lies not so much due in the fact the idea was raised, but that it still existed after the 2,5 year that passed since he first heard about it.
Gawlik was a researcher in the Royal Armament and Development Establishment, a UK Defense R&D organisation. (I tried to retrieve some personal data on Personal data on Gawlik but the Internet failed me).
Why natural language doesn’t work for programming
According to Dijkstra, plain English, or in general language used for human to human communication, is full of nonsense (humor, sloppiness, incompleteness, contradictions, etc.). What is expected from human to computer communication should be precise and unambiguous. Therefore plain language is unfit for the purpose Gawlik aims to use it for, it “is obviously unfit to express what has to be expressed now”.
Dijkstra was right, 50 years later
I guess Dijkstra was proven right. Programming languages based on natural languages are nowhere to be found. The approach from Gawlik is a bit like adding human characteristics to AI systems nowadays: it makes the basically as sensitive to erroneous reasoning as human beings themselves.
Gawlik has written a response in which I sense he argues Dijkstra has not understood the goal of what Gawlik was trying to achieve, but unfortunately I can not find the full article and do not wish to may 19$ for it on ACM (goodness, why?).
Reading Edsger Dijkstra’s technical papers is rarely dry. In EWD 54, while designing critical operating system algorithms for the X8 computer, he explains I/O coordination using hotel guest registers and invents delightful Dutch neologisms like “tandepoetsprogramma” (toothbrushing program). It’s a masterclass in making complex computer science accessible, and entertaining.
The Challenge: Coordinating Drum Storage in 1960s Computing
Before solid-state drives revolutionized storage, computers relied on drum and disk storage, mechanical devices where data access speed depended on physical spindle rotation. Minimizing wait times for the spindle to reach the correct position was crucial for system performance.
In EWD 54, Dijkstra addresses a fundamental challenge: how should an operating system coordinate between waiting processes (what he calls “Abstract Machines”) and physical I/O operations (which run on hardware subsystems like drum storage)?
The complexity is considerable. The system must:
Queue I/O operations efficiently
Notify waiting processes immediately when operations complete
Handle error conditions gracefully
Minimize memory access and usage (measured in bits!)
Optimize drum movements to reduce mechanical delays
Abstract Machines: The consumer processes running in the computer, waiting for I/O operations to complete. These represent the logical programs that need data.
Concrete Machines: The physical hardware subsystems (like drum controllers) that execute the actual I/O operations.
The operating system’s job? Orchestrate the interaction between these two worlds efficiently and correctly.
Making the Complex Comprehensible: The Hotel Analogy
Rather than drowning readers in technical specifications, Dijkstra employed everyday analogies. His most memorable: managing I/O processes is like running a hotel.
Guests = processes requesting I/O operations
Hotel rooms = allocated memory space for each process
Checking out = freeing memory when I/O completes
Rooms are freed using Dijkstra’s own invention: semaphores, the synchronization primitives that would become fundamental to concurrent programming.
This wasn’t just pedagogical whimsy. The analogy helped clarify the essential coordination problem: How do you track who’s waiting, assign resources efficiently, and clean up when operations complete?
Inventing Dutch Computer Science Vocabulary
Perhaps most entertaining is Dijkstra’s creative approach to technical terminology. Writing in Dutch, he coined new phrases that are both precise and playful:
Haastsituatie (racing condition): A timing problem where the outcome depends on the sequence of uncontrollable events. Dijkstra distinguished between:
The essential variant: Must be solved for correctness
The moral variant: Should be solved for efficiency
Tandepoetsprogramma (toothbrushing program): A routine that initializes variables to a clean state—like brushing your teeth before bed prepares you for sleep.
Scattered throughout are delightfully unscientific phrases:
“Dat is toch wel al te gek” (That’s just too crazy)
“Het is natuurlijk erg prettig” (It’s naturally quite pleasant)
“Over de administratie van een bevolking” (About the administration of a population)
The Technical Achievement
Beneath the charming presentation lies serious computer science. Dijkstra presents a high-level algorithm for operating system I/O handling that addresses:
Minimal memory access: Every operation counted when memory was expensive
Robust error handling: The algorithm remains correct even when I/O operations fail
Efficient memory usage: Measured in bits, not bytes or kilobytes
This work contributed to the theoretical foundations of multiprogramming: the ability for computers to run multiple programs seemingly simultaneously by rapidly switching between them.
Why EWD 54 Matters Today
Modern developers might wonder why anyone should care about drum storage optimization in 2025. Several reasons:
1. The principles remain relevant: Coordination between asynchronous operations is still a core challenge, whether you’re managing disk I/O, network requests, or cloud service calls.
2. Dijkstra’s methodology endures: Using clear abstractions, careful reasoning, and accessible explanations makes complex systems understandable.
3. Humor aids understanding: Technical writing doesn’t have to be humorless. Dijkstra proved that rigorous thinking and playful presentation can coexist.
4. Historical perspective matters: Understanding how pioneers solved foundational problems helps us appreciate modern abstractions and recognize when we’re encountering similar challenges in new contexts.
A Nerdy Hobby Worth Pursuing
Reading EWDs has become a hobby. Quite nerdy – I was told. But there’s something satisfying about following Dijkstra’s thought process through these papers. Each one is a glimpse into a brilliant mind grappling with genuinely hard problems while refusing to sacrifice clarity or personality.
If you’ve never explored the Dijkstra archive, EWD 54 is an excellent starting point. It showcases his technical brilliance, his pedagogical skill, and his conviction that computer science should be both rigorous and human.
After all, if you can’t explain drum storage coordination using hotel analogies and toothbrushing programs, are you really understanding it deeply enough?
