Go To Statement Considered Harmful

In the AI Story

The 1960s were a period in which the gap between the machines' capabilities and the profession's ability to program them reliably was becoming catastrophic. Operating systems routinely took years longer to build than planned, and the systems that shipped were riddled with defects that no one could diagnose. The prevailing explanation was that the problems were inherently complex. Dijkstra's counter-argument was that the problems had been made complex by the habits of programmers who wrote code in which execution could jump from any point to any other point, creating programs whose local behavior depended on global context that no reader could track.

The technical argument runs in two steps. First, human reasoning about programs proceeds by decomposing the program into parts, understanding each part, and composing the understandings. Second, this decomposition only works if each part has a bounded interface — a defined entry point, a defined exit point, and a behavior that depends only on what enters and what leaves. The go to statement violates the second condition. A labeled point in the program might be entered from anywhere, which means the block containing it has no bounded interface, which means local reasoning fails, which means the program's correctness can only be established by tracing every possible execution path — a task that scales exponentially with program size.

The response from the profession was immediate and hostile. Programmers who had built careers on fluent use of go to saw the proposal as an attack on their craft. The debate continued for nearly a decade, with Knuth's 1974 "Structured Programming with go to Statements" offering the most prominent defense of disciplined go to use. But the empirical evidence accumulated in the direction Dijkstra had predicted: programs written in structured style were easier to verify, easier to maintain, and easier to understand. By 1985 the argument was effectively settled.

The letter's persistence in the cultural memory of computing comes partly from the force of its title and partly from the fact that its underlying insight is reusable. The structural principle — that arbitrary transfer between contexts destroys the possibility of local reasoning — applies to any system whose behavior depends on the composition of local behaviors. AI code generation is such a system. The builder describes an outcome. The machine produces an implementation. The path from description to implementation is an arbitrary jump that no human reasoning can trace. The generated code may be structured at the surface; the generation process is not.

Origin

Dijkstra had been developing the argument for several years before the 1968 letter appeared. His work on the THE multiprogramming system at the Eindhoven University of Technology between 1965 and 1968 had convinced him that programs of the scale industry was attempting could not be built reliably without the kind of structural discipline he was proposing. The letter was, in effect, a distillation of the operational lessons he had drawn from that project.

The immediate reception was mixed and the long-term influence disproportionate to the letter's length. The paper has been reprinted dozens of times, cited thousands, and imitated in titles so frequently that the phrase "X Considered Harmful" has become a minor genre of technical criticism in its own right.

Key Ideas

Arbitrary transfer destroys local reasoning. A block that can be entered from anywhere has no bounded interface, and without a bounded interface, the block cannot be understood independently of its context.

Correctness is an epistemic claim, not a behavioral one. A program that happens to produce the right outputs for tested inputs is not the same as a program whose correctness can be demonstrated. The go to destroys the second without affecting the first.

The generation process is the new go to. The arbitrary jump in modern AI-augmented building is not in the executed program but in the creation process — the opaque transformation from natural language to code — and it has the same structural consequence: the builder cannot reason about what produced the output.

Structural temptation defeats personal discipline. Even a skilled programmer using go to judiciously produces code that cannot be verified by the methods applicable to structured code. The argument is about what the construct makes possible, not about how it is typically used.

The title is a genre. "X Considered Harmful" has become a rhetorical template, but the original argument had a specific logical structure: the construct's mere availability creates a structural temptation that cannot be contained by individual discipline.

Debates & Critiques

Knuth's 1974 defense of disciplined go to use is the most rigorous pushback the original letter received, and its conclusion — that some limited uses of go to are justified when their structural equivalents would be awkward — has been absorbed into mainstream practice. But the deeper argument Dijkstra was making, that structural temptation matters more than individual competence, has not been refuted; it has been forgotten, which is different. The question for the AI era is whether the lesson needs to be rediscovered at a new layer of the stack.