Tech-inzichten door Niek de Greef. Reflecties op technologie, software development en de impact van digitale innovaties op cultuur en maatschappij.

Edsger Dijkstra: the world’s first tech blogger (Before the Internet existed)

Imagine a world-renowned computer scientist who publishes informal notes covering everything from theoretical algorithms to travel complaints to angry letters about programming language design. He writes with wit, uses everyday analogies, coins playful terminology, and distributes his thoughts in numbered manuscripts to anyone interested.

Sound like a modern tech blogger? This was Edsger Dijkstra in the 1960s. Decades before the internet, let alone blogging platforms, existed.

Who was Edsger Dijkstra?

Edsger Wybe Dijkstra (1930-2002) was a Dutch computer scientist whose influence on programming is hard to overstate. He:

  • Created the shortest path algorithm (Dijkstra’s algorithm), foundational to GPS, routing, and network protocols, and, for the math nerd, really a super elegant approach
  • Invented semaphores, the synchronization primitives that enable concurrent programming
  • Championed structured programming, helping eliminate the chaos of “spaghetti code”
  • Won the 1972 Turing Award, computing’s highest honor

But beyond these technical achievements, Dijkstra was a remarkable communicator with a distinctive literary style, something rare in computer science then and now.

The EWD manuscripts: a blog before blogs

From 1959 until shortly before his death, Dijkstra wrote over 1,300 manuscripts labeled “EWD” (his initials: Edsger Willem Dijkstra) followed by a number. These weren’t formal academic papers submitted to journals. They were something else entirely. Something we’d now recognize instantly as blog posts.

What made EWDs blog-like?

Frequency and Informality: Unlike academic papers that took months or years to publish, Dijkstra wrote EWDs whenever inspiration struck. Some were polished drafts of papers; others were rough notes, travel observations, or rants dashed off in response to current events in computing.

Range of Topics: Just as a modern blogger might write about their technical expertise, their travels, and their opinions on industry trends, Dijkstra’s EWDs covered:

  • Deep theoretical computer science
  • Algorithm designs and proofs
  • Trip reports from conferences
  • Critiques of programming languages and practices
  • Philosophical reflections on education
  • Complaints about bureaucracy

Personal Voice: Academic writing demands objectivity and formality. Blog writing encourages personality. Dijkstra’s EWDs read like conversations with a witty friend who happens to be explaining complex algorithms.

Open Distribution: Dijkstra physically mailed photocopies of his EWDs to colleagues and interested parties worldwide. This was his subscription list, a pre-internet version of email newsletters or RSS feeds.

Handwritten Format: Most EWDs were handwritten (Dijkstra famously avoided using computers for writing), giving them an intimate, personal quality, like reading someone’s notebooks rather than their published works.

Dijkstra’s voice: precision with personality

What makes the EWDs exceptional isn’t just their content, it is how Dijkstra wrote. Consider this opening from EWD 28, launching into a theoretical discussion about machines and languages:

“A machine defines (by its very structure) a language, viz. its input language: conversely, the semantic definition of a language specifies a machine that understands it. In other words: machine and language are two faces of one and the same coin. I am going to describe such a coin. I leave it entirely to you to decide which of these two aspects of the subject matter of my talk you think the most important as it is rather ridiculous in both aspects.”

That final phrase – the “rather ridiculous in both aspects” – is pure Dijkstra. He’s about to present serious theoretical work, but he can’t resist acknowledging its absurdity. This is intellectual honesty with a wink.

Examples of Dijkstra’s humor and style

Hotel Analogies: In EWD 54, explaining complex I/O coordination, Dijkstra compares process management to running a hotel. Guests check in (processes request I/O), occupy rooms (memory allocation), and check out (operations complete). It’s technically precise and charmingly accessible.

Invented Terminology: Writing in Dutch, Dijkstra coined “tandepoetsprogramma” (toothbrushing program) for initialization routines that clean up state, because they prepare the system like brushing your teeth prepares you for sleep.

Casual Asides: Throughout technical discussions, you’ll find phrases like:

  • “Dat is toch wel al te gek” (That’s just too crazy)
  • “Het is natuurlijk erg prettig” (It’s naturally quite pleasant)

Cutting Criticism: Dijkstra could be merciless when critiquing bad practices. His famous quote (or at least, famously attributed to him): “The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense.”

Why the EWDs still matter

Modern developers might wonder why anyone should read computer science papers from the 1960s-1990s. Several reasons:

1. The Writing Is Timeless: Dijkstra’s explanations remain clear and insightful regardless of technological changes. His discussion of elegance in programming (EWD 32) is as relevant today as in 1962.

2. Foundational Concepts: Many principles Dijkstra explored (concurrency, abstraction, correctness) are more important than ever as systems grow more complex.

3. Model for Technical Communication: Dijkstra proved that rigorous thinking and engaging writing aren’t opposites. Technical bloggers today are, consciously or not, following the path he blazed.

4. Historical Perspective: Understanding how pioneers grappled with fundamental problems helps us recognize when we’re encountering similar challenges in new contexts.

5. Pure Intellectual Pleasure: The EWDs are simply enjoyable to read. How many technical documents can claim that?

The Biography That Should Exist

Despite Dijkstra’s influence and fascinating life, there’s no comprehensive biography that captures both his technical genius and his literary personality. Most accounts focus on his algorithms and awards, missing the human complexity that made him remarkable.

A proper Dijkstra biography would explore:

  • His unconventional path (initially studying physics, his theoretical approach to a practical field)
  • His relationships with other computing pioneers
  • His fierce advocacy for rigor in programming
  • His teaching philosophy and influence on students
  • The development of his distinctive writing style
  • His role as a Dutch scientist in an American-dominated field
  • His prescient warnings about software complexity that proved prophetic

Someday, someone needs to write this book. Maybe I’ll end up kickstarting it myself.

Reading the EWDs today

The complete Dijkstra Archive is available online at the University of Texas, where his papers are preserved. You can read every EWD, often with both scanned handwritten originals and typed transcriptions.

Each is a glimpse into a brilliant mind that refused to sacrifice clarity or personality for technical precision, because Dijkstra understood that good thinking requires both.

For today’s technical writers

Dijkstra’s EWDs offer a challenge to modern technical bloggers, documentation writers, and computer science communicators: Can we match his combination of rigor and readability? Can we make complex ideas accessible without dumbing them down? Can we be both precise and personal?

The best technical writing today, whether it’s blog posts, documentation, or papers, channels something of Dijkstra’s spirit: deep knowledge presented with clarity, humor, and humanity.

In that sense, every thoughtful technical blogger is continuing Dijkstra’s project. We’re all writing EWDs now; we just call them blog posts and press “publish” instead of photocopying and mailing them.

But we should aspire to write them half as well as Dijkstra did, with his elegance, his wit, and his refusal to let rigor become rigid or science become sterile.

Further Reading:

Related Articles on This Blog:

EDW 37 – a review of the new IBM 1620

In EWD 37 Dijkstra records a product review of the the new IBM 1620 computer, which came to the market in 1959.
As often, the article starts with a wonderful Dijkstra-esk introduction.

It is a good custom that scientific articles are reviewed and that no publisher ever thinks about starting a lawsuit or any other measures of vengeance against the author of a very unfavourable review of one of his publications.

He continues,

With this in mind it is somewhat curious that it is not customary to review digital computers. Reviews of these scientific instruments are in some respects much more important: it is a pity if you have bought the wrong book, but it is much, much worse if you have bought the wrong computer.

Foto from http://www-03.ibm.com/ibm/history/exhibits/mainframe/mainframe_PP1620.html

I am not sure if it is the first review of a new computer ever, but it is an interesting one, and it goes quite deep into the technical aspects.
(BTW for the historians amongst us, the 1620 was considered the first “mini-computer”.)

It is my considered opinion, however, that this machine embodies some very fundamental mistakes and certainly after the publication of the two letters mentioned above I regard it as my duty not to remain silent any longer. Manufacturers should be warned for these mistakes in order not to be tempted to incorporate them in their future designs, also machine users should be warned for these mistakes in order to help them in not chosing the wrong machine and in order to create a climate where machines will be judged more by their fundamental properties.

Dijkstra surfaces two major flaws in the design of this computer.
An instruction for constructing subroutines (Branch And Transmit) that is basically unusable because it is impossible to use in nested subroutines.

Another problem Dijkstra identifies is with the design of the paper tape processing. And it wouldn’t be Dijkstra if he would not illustrate this shortcoming with a great metaphor.

But now a curious problem arises: the terminal Record XXX Mark which has been stored is indistinguishable from previous Record Marks which might have been read from the tape, and therefore the machine is faced with a problem that shows a striking resemblance to the prototype of an improper algorithm: a man asking the way and getting the answer “You go straight on and turn to the right just before the last steel bridge.”

Dijkstra goes on to criticize the implementation of the variable field addressing method. He proves the implementation in not only very uneconomic (wasting memory – “cores”), but also severely limiting memory management. So severe that he questions the intelligence of the designers of the computer.

I always wonder whether the designers of such machines have been aware of the restrictive consequences of the technique in question; if so, it is hard to respect their conscious decision to stick to it, if not, are they the people that should have been designing machines? I always wonder……

Looking at these shortcomings they seem quite hilarious, but these were the early days of computing.

Dijkstra concludes his review with a final scathing verdict. Not only the buyers must have been totally ignorant to have bought such a machine, also the manufacturer is to blame.

As the reader will understand, my recent study of the IBM 1620 has been a shocking experience: I knew that it was a rather small machine but I had never suspected that it would embody so many basic blunders. Personally, I cannot undergo such an experience without asking myself what its morals are.
One of the facts we have to face is that this machine, despite of its poor qualities, has been bought or rented. Either the customer is incompetent to judge what he is buying, or the contracts are signed by the wrong persons; in both cases the conclusion is that the fact, that other people have chosen a particular machine, is no guarantee whatsoever as far as its quality is concerned.
…
The next fact that we have to face is that this machine, despite of its poor qualities, has been produced, in this case even by a big firm with a long and considerable experience. The straightforward conclusion is, that nor the size nor the experience is a guarantee as far as the quality of the product is concerned. Well, we can think of various explanations for this apparent inconsistency, but the most obvious explanation predicts still more blunders in the more ambitious and more complicated products of the manufacturer in question.

Thank you very much. There you go, IBM.

Sloppy Lifebox print, excellent read from Rudy Rucker

Annoying: pages 237 through 240 are shuffled in my print of The Lifebox, the Seashell and the Soul. Though not entirely surprising, the crumbly paper was an indicator of a sloppy edition. Maybe it is a collector’s item now. Mail me and you can have it.

I bought it about ten years ago, and recently reread Rudy Rucker’s The Lifebox, the Seashell and the Soul It is a very interesting book, although it smells odd here and there.  

Rucker writes about Alan Turing that Turing ‘apparently was given to bringing home sexual partners he met in the streets.’ What does he mean with that phrasing? For historical facts on Turing, I prefer to rely more on Turing’s biographer Andrew Hodges who wrote the respectable biography Alan Turing: The Enigma. Hodges pictures Turing as naive in confessing his homosexuality (for that time), but also describes him to be rather restraint in getting involved in sexual relationships. What I am sure I haven’t read anywhere is that Turing would go skimming the streets looking for ‘sexual partners’ (sexual partners – is that really correct English?).

Also the idolizing references to Stephen Wolfram’s A New Kind of Science are unnecessary. Wolfram generously takes care of that himself.

Also, Rucker’s habit of regularly quoting his own Science Fiction stories to illustrate his theories begins to annoy me at some point. I understand his frame of reference, but he is not very scientific in this way of providing ‘proof’.

But, as said, the book offers a number of very interesting ideas and visions. I realize I sound so negative, but I really enjoyed the book.

Rucker confirms that Artificial Intelligence – the discipline in Computer Science – has not achieved a lot. After my personal introduction to scientific AI, I became very suspicious. I found it odd that AI was dealing with decision rules, (fuzzy) logic, and the like. And used this awful programming language Prolog. Wasn’t there anything better to focus on in Artificial Intelligence? Cognitive is hot these days, but is it really Artificial Intelligence? A step forward, probably.

Rucker describes the life box—a device that captures every aspect of your life. I’m not sure if he invented the concept, but it is the first time I saw it described in such a realistic, predictive way.

This book has become history. The lifebox is there. People like Cathal Gurrin are walking around with cameras and devices recording everything they do all day.