Why Coupland reminded me of Booch while reading the rollercoaster novel All Families Are Psychotics

All Families Are Psychotic is a journey through the chaotic events of a family get together.

I love these books from Douglas Coupland where the story brings you semi-random from one idiotic hilarious episode into the other. Btw why does Douglas Coupland remind me of Grady Booch? Both seem a bit scruffy outliers in their worlds – is how I would describe it in an instant answer without much further thought. It the same thing that attracts me in Haruki Murakami’s novels – the semi randomness of the events that lead the protagonists(s) through the story. The story is the way.

Grady Booch on the Future of Software Engineering
Booch

I believe my family is psychotic, but this Drummond family excels at it. What starts off as a family event around daughter Sarah’s jump into space – she’s an astronaut, develops into a wild road movie, with lots of collateral damage. So take Coupland’s title with a touch of salt, but it’s a great rollercoaster read.

Douglas Coupland
Coupland

While you are at it also read Coupland’s Player One which has a similar cadence.

I your more have time to shred also read Murakami trilogy 1q84.

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:

Watching the birth of modern computing – EWD 35

EWD 35 starts out in typical Dijkstra way.

It is not unusual for a speaker to start a lecture with an introduction. As some in the audience might be totally not familiar with the issues that I wish to address and the terminology, which I will have to use, I will to give two examples as a means of introduction, the first one to describe the background of the problem and a second one, to give you an idea of the kind of logical problems, that we will encounter.

The story that EWD 35 tells is a brief history of the resolution to the scientific topic that brought Dijkstra his fame: the problem of synchronising parallel processes and the invention of the the concept of the semaphore for these types of problems in computing.

Today it is almost impossible to imagine a time in which this problem was still unsolved. Collaborating parallel processes, semaphores and indivisible operations have become a such a commodity in computing. But at that time computing meant sequential processes and parallelism of interacting processes was being looked at for the first time.

In 1959, the question was of whether the described capability for communication between two machines made it possible to couple two machines such, that the execution of the critical sections was mutually excluded in time. In 1962, a much wider group of issues was considered and the question was also changed to “What communication possibilities between machines are required, to play this kind of games as gracefully as possible?”

A side note. The word “required” and “possibilities” here do not cover the meaning of Dijkstra’s original in Dutch “welke communicatiemogeljkheden tussen machines zijn gewenst”. I would say “which communication facilities between machines are desired” – expressing better that Dijkstra is in the mode of designing the thing, thinking up these communication facilities.

Another side note, much of Dijkstra’s beautiful loose writing in Dutch is lost in this straightforward translation to English here. For example, we can translate “Jantje” to “Johnny” but in Dutch we have a completely different image in our head when we see Jantje than we someone, Dutch or non-Dutch, would have with Johnny.

Dijkstra uses the word machines in the paragraph quoted above. The terminology developed further and today we would call these, a bit more abstract, processes.

Further in his article he gives an insight into the potential for his “machines” and sees them simulated on a central computer. We really have to imagine this is a remarkable insight in the future. At that time computer ran single tasks. Running multiple processes at the same time on the same hardware was at best experimental. He makes this remark in the context of alternative ways of having machines collaborate and let them wait on each other by building in wait times in case they need access to the same resource.

However, if we consider now, that will be the majority of these machines will be simulated by a central computer so that any action in one machine can only be performed at the expense of the effective speed of the other machines, then it is very costly using a wait cycle to demand attention of the central computer for something completely useless.

The basic problem Dijkstra extensively examines is best described by Dijkstra in the following sentences. One machine wants to assign a value to a shared variable, after testing its value. For example something like:

if x=3 then x :=4 else x:=5

Another machine is trying to do the same thing, at the same time. What happens if machine 1 tests for the value of x, while at the same time machine 2 changes this value. Or, what happens if they both change the value of x at the same.

Dijkstra indicates a mechanism is necessary which he call indivisible actions. Today these things are indivisible, uninterruptible or atomic operations or instructions.

These two actions, assigning a new value and inquiring about the current value are considered indivisible actions, i.e. if both machines wish to “simultaneously” assign a value to a common variable then the value assigned at the end is one or the other value, but not some mixture. Similarly, if one machine asks for the value of a shared variable at the time that the other machine is assigning a new value to it, then the requesting machine will receive or the old or the new value, not a random value.

Having these instructions is key to the solution of the problem of interaction sequential processes.

In EWD35 Dijkstra then goes on to describe, in a rather lengthy paragraph – but remember this was front end research at that time – the invention of the semaphore in computing.

The programmed wait cycle that exists herein, is of course very nice, but it did little to what our goal. A tiny wait cycle is indeed the way to keep a machine busy “without effect” . However, if we consider now, that will be the majority of these machines will be simulated by a central computer so that any action in one machine can only be performed at the expense of the effective speed of the other machines, then it is very costly using a wait cycle to demand attention of the central computer for something completely useless. As long as the wait cycle cannot be exited, in our opinion the speed of this machine may be reduced to zero, To express this we introduce a statement instead of wait cycle, a basic instruction in the repertoire of the machines, that may take a very long time. We indicate this with a P (to Pass); in anticipation of future needs, we represent the statement “SX: = true” by “V(SX) – with V of “vrijgave” (in English: release) (This terminology is taken from the railway environment. In an earlier stage the common logical variables were called “Semaphores” and if their name starts with an S, it is a reminiscence of it). The text of the programs in this new notation is as follows:

“LXi: P(SX); TXi; V(SX); proces Xi; goto LXi” .

And you hold your breath, watching the birth of modern computing here in EWD 35.

The rest of the article provides the proof that this mechanism holds for any number of machines.

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: