On the Cruelty of Really Teaching Computing Science

In the AI Story

The essay was composed in 1988, a moment when the undergraduate computing curriculum was already drifting toward the pattern it would follow for the next three decades: programming taught as a craft learned by doing, with formal methods relegated to elective advanced courses. Dijkstra saw this drift as a surrender — a decision to teach students the habits of trial-and-error programming precisely at the point when their habits were most impressionable and hardest to revise later.

The essay's title captures the pedagogical paradox: really teaching computing science requires cruelty in the specific sense that it requires denying students the immediate gratification of watching their code execute. Code that executes teaches nothing about whether the code is correct. What teaches correctness is the discipline of deriving programs from specifications and verifying them through logical reasoning. This is harder than trial-and-error; it produces, in the short term, less visible output. In the long term it produces programmers who know what they are doing.

The argument extends directly into the AI era, and the extension is sharper than in 1988 because the tool is more powerful. Natural language interfaces allow students to produce working code without understanding any of the formal reasoning that would once have been required. The student who describes a sorting function and accepts the output has skipped the struggle that would have taught her what sorting is. She has the artifact; she does not have the understanding.

The pedagogical response Dijkstra's essay demands is counterintuitive and unwelcome: the response to AI-generated code is not less programming instruction but more, and of a specific kind — instruction in reading and evaluating generated output with the critical judgment the generation process does not provide. This is a form of literacy: the ability to read code, even if one cannot write it. A curriculum that teaches students to prompt effectively without teaching them to evaluate the output produces, in the essay's logic, fluent illiterates — people who can generate text they cannot read.

Origin

The essay was delivered first as a lecture in 1988 and circulated as EWD1036. It is one of the most-cited of Dijkstra's manuscripts outside the narrow technical literature and has been particularly influential among computer science educators, though its direct recommendations have been implemented in few places.

The closest contemporary descendant is the "verification literacy" movement in computing education — the argument that students must be taught to read and reason about code, not merely to write it — which has gained traction as AI-generated code has become ubiquitous.

Key Ideas

Prerequisites are logical, not technological. Programming is a mathematical discipline; its prerequisites are mathematical; access to a machine is not a prerequisite for learning but a potential obstacle to learning well.

Tools amplify whatever the user brings. The scalpel does not distinguish competence from incompetence; the user's understanding does. The same holds for the compiler, the debugger, and now the language model.

Cruelty as a pedagogical necessity. Withholding immediate gratification is harder to justify than granting it, but the long-term cost of teaching bad habits is greater than the short-term cost of teaching discipline.

Literacy over authorship. The skill that matters most in the AI era is not the ability to write code but the ability to read and evaluate it. A curriculum that teaches prompting without verification produces fluent illiterates.

The impression age matters. Students are most impressionable at the beginning; the habits formed then are hardest to revise later. Teaching trial-and-error early makes formal reasoning a permanent second language.

Debates & Critiques

The essay provoked and continues to provoke vigorous pushback from practitioners who argue that Dijkstra's pedagogy is suited only to a tiny minority of students and that most programmers never need formal reasoning skills to build useful software. The Dijkstrian rejoinder is that useful and correct are different words, and the software the public actually uses fails often enough, in consequential enough ways, that the question of whether its builders could reason about it formally is not merely academic.