Go To Statement Considered Harmful

The situation

By the late 1960s software was in trouble. Large projects ran late, over budget and full of errors; a NATO conference in 1968 popularised the phrase “software crisis”. Programs were often written as long sequences of instructions connected by jumps, the go to statement, which transferred control to any labelled point in the program. This was flexible and close to how the machine worked, and it produced code whose behaviour could be very hard to follow.

Edsger Dijkstra, a Dutch computer scientist who had helped build one of the first compilers for ALGOL 60, had been thinking about how programmers could reason about the correctness of their programs. Earlier theoretical work by Corrado Böhm and Giuseppe Jacopini, published in 1966, had shown that any program could in principle be written using only sequence, selection and repetition, without arbitrary jumps.

What it argues

Dijkstra’s letter begins with an observation he says he had been familiar with for some years: “the quality of programmers is a decreasing function of the density of go to statements in the programs they produce.”

The argument behind the provocation is about human minds. “Our intellectual powers are rather geared to master static relations,” he writes, while “our powers to visualize processes evolving in time are relatively poorly developed.” A program is a static text, but what matters is the process it produces when it runs. The programmer’s job is therefore to make the two correspond as closely as possible: to “shorten the conceptual gap between the static program and the dynamic process.”

Structured constructs help because they make position in the text tell you about position in the computation. If you know you are inside a loop on its fifth repetition, you know where you are. Unrestricted jumps destroy that correspondence. After a go to, you cannot tell from the text how you arrived or what is true at that point. Dijkstra concluded that the go to statement was too primitive and should be removed from higher-level languages.

His manuscript was titled “A Case against the GO TO Statement”. The title by which the letter is famous, “Go To Statement Considered Harmful”, was supplied when it was published in Communications of the ACM in March 1968, and it became a template for countless later polemics.

The idea underneath

The deepest part of the letter is not about programming at all. It is a claim about bounded rationality: human beings are better at grasping structures than processes, so tools should be shaped to fit that limit. A programming language, on this view, is not just a way of instructing a machine. It is an instrument for helping a limited human mind understand what the machine will do.

That makes the letter an argument about legibility of a particular kind: making a system’s behaviour visible in its structure. It is a case where restricting freedom increases capability. The programmer gives up arbitrary jumps and gains the ability to reason about the program.

The programming languages essay argues that every language embodies a theory of the programmer. Dijkstra’s letter makes its theory explicit: the programmer is a limited mind who needs structure to think clearly.

How it was received and what followed

The letter provoked fierce debate. Many programmers defended go to as necessary for efficiency or for handling errors and exits. In 1974 Donald Knuth published a long, balanced paper, “Structured Programming with go to Statements”, showing cases where disciplined use of go to produced clearer or faster code, while largely endorsing the goals of structured programming. Over the following decades, structured programming became the norm. Languages such as Pascal, C and their successors emphasised structured control flow; many later languages omitted go to altogether or restricted it severely, while adding structured ways to handle exceptional exits.

Reading it today as a decision-maker

The letter’s lasting value is its form of argument. Dijkstra did not say go to was ugly. He said it worked against a known limit of human cognition. Arguments of that form, grounded in how people actually understand things, are more persuasive and more durable than arguments from taste. Product and organisational design rules can often be stated the same way.

It is also a reminder that removing options can make people more capable. Many product decisions, about defaults, constraints and structure, involve the same trade: less freedom, more understanding. The opinionated defaults pattern collects such cases.

Sources and limitations

Quotations are from the transcription of Dijkstra’s manuscript EWD215 in the University of Texas archive, which notes that the published version appeared in Communications of the ACM and that the last two paragraphs and references were added for publication. Wording may differ slightly between manuscript and published version. The ACM version is available through the ACM Digital Library. Knuth’s response is summarised rather than quoted.