Dijkstra Q&A

Found this on geekchic.com, a website that has disappeared, but the wayback machine caught it.

  • What is your programming language of choice? my own (Algol? – Kneut)
  • What is your favorite operating system? I don’t use a computer
  • Do you have a hero or role model? not really
  • What is your favorite kind of music? chamber music
  • What is your favorite news group? I don’t use a computer
  • What is your favorite web page (besides geekchic!)? I don’t use a computer
  • What sports do you enjoy? none
  • What kind of car do you drive? AUDI 4000
  • What hobbies do you enjoy outside of work? music, photography, camping
  • What is your favorite book (or author)? Dorothy L. Sayers
  • What is your favorite movie? Roman Holiday
  • What sort of clothing do you usually wear to work? informal, T-shirt, sandals
  • What is your favorite food? soups

EWD139 – On punch cards for the X8

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.

control room of the Grande Dixence project in the vicinity of Zermatt, Switzerland
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.”

X8 electrologica

EWD 108 and EWD 116 – about the banker’s algoritm

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).

EWD68, plain English unfit for programming

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).

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”.

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?).

Interacting with the drum – Dijkstra on multiprogramming and I/O handling

The X8 computer

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 vs Concrete Machines

Dijkstra’s conceptual framework distinguished between:

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:

  1. Minimal memory access: Every operation counted when memory was expensive
  2. Optimal drum movements: Reducing physical motion improved performance dramatically
  3. Robust error handling: The algorithm remains correct even when I/O operations fail
  4. 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?

Further Reading:

Related articles:

Singularity Is Near – Kurzweil meets Dijkstra

the singularity is near Ray Kurzweil book cover

While reading Ray Kurzweil’s The Singularity Is Near, I stumbled upon a quote attributed to computer scientist Edsger W. Dijkstra that made me pause, not because of what it said, but because of how it was used.

The Disputed Quote

Kurzweil cites Dijkstra as saying: “Computer Science is no more about computers than astronomy is about telescopes.”

It’s a clever aphorism that sounds exactly like something Dijkstra would say. There’s just one problem: the attribution is disputed, and the original source remains elusive.

Searching for the Source

I dove into the Dijkstra archive at the University of Texas, which contains his extensive collection of EWD manuscripts. Despite searching through his papers, I couldn’t find this exact quote. Wikiquote also lists the attribution as disputed.

Could Dijkstra have said it? Absolutely. Despite being a world-renowned computer scientist, he famously avoided using computers for his work, reportedly owning one only to read email and browse the web. For him, computer science truly was about ideas, not machines.

But the lack of a verifiable source matters—especially in a book making grand claims about the future.

Context Matters: Why This Quote Feels Out of Place

Kurzweil places this quote in a chapter discussing exponential growth, Moore’s Law, and paradigm shifts. But the connection feels forced. The Dijkstra quote speaks to the philosophical nature of computer science as a discipline. It doesn’t illuminate anything about exponential technological progress or the coming singularity.

This seemingly minor misplacement reveals a larger issue with The Singularity Is Near: the blending of rigorous scientific facts with personal predictions that lack the same level of substantiation.

Two Visionaries, Two Approaches

The contrast between Dijkstra and Kurzweil is instructive:

Edsger Dijkstra: An unconventional theoretical scientist known for mathematical rigor and precision. Every statement in his EWD manuscripts was carefully reasoned and documented.

Ray Kurzweil: An unconventional futuristic engineer and inventor. His predictions are bold, optimistic, and often based on extrapolating current trends.

You might expect Dijkstra to be dry and academic, while Kurzweil would be the more engaging personality. But here’s the surprise: the biggest difference between their work isn’t their subject matter or their ambition—it’s humor.

The Missing Ingredient: Humor

Dijkstra’s writings are filled with wit, self-awareness, and intellectual playfulness. He could be cutting in his criticism, but always with a touch of humor that acknowledged the absurdity of certain positions. This humor wasn’t just stylistic. It was a sign of intellectual honesty and humility.

Kurzweil’s The Singularity Is Near, despite its grand vision and fascinating ideas, takes itself entirely seriously. Every prediction is presented with confidence. Every trend will continue. Every obstacle will be overcome. There’s little room for doubt, irony, or the acknowledgment that futurism is, by nature, speculative.

The Problem with Unquestioning Optimism

This lack of humor—and the self-awareness it represents—makes Kurzweil’s predictions less credible, not more. When you can’t laugh at yourself or acknowledge the limits of your knowledge, you risk becoming a prophet rather than a scientist.

Dijkstra understood that computer science required both rigor and humility. He documented his sources, admitted when he was speculating, and never confused his hopes with inevitability.

Kurzweil’s work would be stronger if it borrowed more from Dijkstra’s approach: not just his ideas, but his intellectual honesty.

What We Can Learn

The misattribution (or at least unverified attribution) of the Dijkstra quote is a small detail, but it’s emblematic. It suggests a book that prioritizes narrative momentum over scholarly precision. That’s not necessarily wrong for a work of futurism, but readers should understand what they’re getting: a compelling vision more than a rigorous prediction.

When reading about the future of technology, it’s worth asking: Is this backed by verifiable evidence, or is this someone’s optimistic extrapolation? Are the sources documented? Is there room for doubt?

Dijkstra would have insisted on all three.

Further Reading:

Related posts:

Dijkstra in EWD 32 on the tool, how it should be worthy our love, and show: Elegance and Beauty

E.W. Dijkstra and McJones at a conference in marktoberdorf 1973

Reading Dutch computer scientist Edsger Dijkstra’s EWD’s.

The State of Programming in 1962

In EWD 32 Dijkstra shares his “meditations” on the state of the Art (or rather Science, as he prefers to say) of Programming. Machine design was ugly, programming as a discipline was undeveloped. This was 1962.

Programmers were hired for applying tricks and Dijkstra loves the development that there is

… the slowly growing group of people who think it more valuable that the man should have a clear and systematic mind.

The Commercialization Problem

He goes on to discuss how programmers and machine designers should collaborate to create better machines and programming languages. This was very necessary because Dijkstra believed that at that time, the computer manufacturing industry was taking over computer design from universities. But this brought a commercial angle to computer design that Dijkstra was unhappy with.

They seem to design for the customer that believes the salesman who tells him that machine so-and-so is just the machine he wants.

What Dijkstra Meant by “The Tool”

Dijkstra goes on to share his thoughts on how to improve The Tool – by which he means the programming language, translator, and machine. Nowadays, with so many languages and machines, we hardly think about this tool. We think of tools as tools: a given rather than a thought. And of course, we have massive debates about programming languages, hardware, etc. But some of the concerns have disappeared. Nobody really seems to care about machine design anymore. It has become a commodity. It should be fast and robust. Hardware hardly provides any distinguishing features. If so, it is about size and energy, not about performance and reliability.

The Eternal Quality: Elegance and Beauty

But the last one he mentions is an eternal difference, one which we still haven’t landed on. And maybe we never will. Because it is a subjective one. A characteristic you wouldn’t expected in our Beta world of computers and programmers.

As my very last remark I should like to stress that the tool as a whole should have still another quality. It is a much more subtle one; whether we appreciate it or not depends much more on our personal taste and education and I shall not even try to define it. The tool should be charming, it should be elegant, it should be worthy of our love. This is no joke, I am terribly serious about this. In this respect the programmer does not differ from any other craftsman: unless he loves his tools it is highly improbable that he will ever create something of superior quality.

At the same time these considerations tell us the greatest virtues a program can show: Elegance and Beauty.

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:

Richard Dawkins and the Expert’s Pitfall: A Critique of The Selfish Gene Footnote

the selfish gene - richard dawkins book cover

The Vile, Yet Correct Critique of Hoyle

In the 30th anniversary edition of ‘The Selfish Gene’ (2006), Richard Dawkins writes a vile but correct comment on Fred Hoyle’s misrepresentation of Darwinism in an endnote (pp. 277-278). He ends his note:

Publishers should correct the misapprehension that a scholar’s distinction in one field implies authority in another. And as long as that misapprehension exists, distinguished scholars should resist the temptation to abuse it.

This is a very accurate observation. But on the same page, in the note referenced in the main text (page 59 of the 30th Anniversary edition), Dawkins almost falls into the trap himself.

richard dawkins portait photo
Richard Dawkins

The Stain on the White Robe: Dawkins’ Error

The note’s text to the main text is so incredibly incorrect that it is pretty funny, given that he does this on the same page as his scolding of Hoyle.

In the note, Dawkins wants to explain Daniel Dennett’s theory of consciousness. Although Dennett has tried to explain his ideas in several books, Dawkins wants to summarize Dennett’s work in this two-page note for unclear reasons.

daniet dennett portrait photo
Daniel Dennett

Incorrect Analogies from Computer Science

Dawkins takes two technical ideas from the world of computers to illustrate his ideas: the concept of a virtual machine and ’the distinction between serial and parallel processors’.

The Virtual Machine

Dawkins starts by explaining what a virtual machine is incorrectly. He mentions the Macintosh User Interface as an example of a virtual machine. The Mac is a great machine, but the Macintosh User Interface bears little resemblance to a virtual machine, and the connection with consciousness remains very unclear. Dawkins could have relied on the Wikipedia article for a correct description of virtual machines.

A virtual machine (VM) is a software-based “computer within your computer.” It lets you run a separate operating system (like Windows or Linux) in an isolated window, using your existing hardware. It’s like having a sandboxed PC inside your real one.

Serial and Parallel Processors

The story derails entirely when Dawkins turns to his description of ‘serial and parallel processors’. The piece is so incorrect that highlighting the individual errors here makes no sense. Since Dawkins fails to see the distinction between processors and processes. He starts wrong and worsens things in every sentence. And it’s not like this was rocket science at the time of writing. Parallel processing has been known and applied in computing since our own Edsger Dijkstra and others invented concepts like the semaphore and the indivisible instruction.

More linkages to Dennett’s work and that of his friend Douglas Hofstadter on page 59, where Dawkins discusses self-awareness and rejects ideas of self-awareness because

douglas r. hofstadter portrait photo
Douglas R. Hofstadter
godel escher bach by hofstadter book cover

it involves an infinite regress if there is a model of the model, why not a model of the model of the model …?

‘The Mind’s I‘ and also ‘Gödel, Escher, Bach – An Eternal Golden Braid‘ deal exactly with these issues.

The Salvation: A Self-Aware Disclaimer

So, can we conclude that Dawkins has fallen into the trap of asserting that a scholar’s distinction in one field implies authority in another?

As I said, almost. On page 280 Dawkins saves himself, on the edge, with this little remark:

the minds I by hofstadter book cover

‘The reader is advised to consult Dennett’s own account when it is published, rather than rely on my doubtless imperfect and impressionistic – maybe even embellished – one.’

How true.

I have never had such fun with academic footnotes.

linning the books of dennett, dawkins and hofstadter