Programming considered as a human activity
E. Dijkstra · Texas Digital Library (University of Texas) · 1979
When looking back on any kind of movement or revolution, one always likes to point to a beginning: It began right there --- it all started with so-and-so's famous speech . . . . If structured programming can be thought of as a revolution, then surely Dijkstra's landmark paper, Programming Considered as a Human Activity, published in 1965, marks its beginning. Virtually entire gospel of structured programming is contained in a few short pages: arguments against goto statements, notion of top-down design, emphasis on program correctness and quality (or elegance, as Dijkstra prefers to call it), and strong argument against programs that modify themselves. In addition to these fundamental concepts, there are some rather classic phrases that first appeared in this paper, and that have popped up in dozens of subsequent articles and books. For example, when discussing divide and conquer approach characterizing top-down design, Dijkstra admits, have only a very small head, and must live with it. What seems obvious to us today was a rather novel idea in 1965: idea that while computers were --- and still are --- getting faster and more powerful, human beings weren't. This theme is repeated again and again, and is essentially entire subject matter of Dijkstra's 1972 speech, Humble Programmer [included as Paper 10 in this collection]. It is in 1965 paper, which you are about to read, that Dijkstra suggests that the quality of . . . programmers was inversely proportional to density of goto in their programs. And, it is in this early paper as well that Dijkstra recounts programming experiments identical to ones that converted most of rest of us to structured programming over next several years: He rewrote unstructured programs into equivalent structured programs, and marvelled at increase in clarity. After reading all pearls of wisdom that are contained in this one paper, one might well ask why programming industry wasn't converted at once. The answer, I think, has to do with timing and packaging. In 1965, most programmers (and their managers) felt that they had far more serious problems to worry about than eliminating goto statements After all, IBM had just unleashed 360 upon world, and whole armies of people began trying to upgrade from Autocoder to RPG --- that is, /f they could get hardware and operating system to work! Programmers spent most of their time trying to figure out how to use more gotos, not fewer --- in hopes that doing so would help them fit some ponderous accounting application into an 8K machine! Another reason for slow adoption of methods was a factor as well of medium in which message was presented --- IFIP Conference, which might be loosely thought of as international version of National Computer Conference. Prestigious and scholarly, to be sure, but its published papers attract a considerably smaller reading audience (at least in ~ United States) than, say, ComputerworM or Datamation. Perhaps only reason it attracted any American attention at all was that IFIP Conference was held in New York City that year --- in contrast to 1971 Conference, which was held in Ljubljana, Yugoslavia! An additional problem preventing widespread conversion was with language itself! Introductory quotations came from scientists Ludwig Boltzmann and George Boole, names with which average programmer is unlikely to be acquainted. Examples chosen in support of concepts involved prime factors of a twenty-digit number --- not a subject of intense interest to many programmers. Discussions in support of structured programming dealt with features of ALGOL 60, well known to American programmers as one of their least popular languages. In short, it's a wonder anyone read paper at all! But once you do read it, you can see why Dijkstra has reputation he does. His writing is succinct and yet convincing. Reading Dijkstra, someone said, has been compared to eating marzipan --- it's best to take very small bites, chew slowly, and digest mouthful before moving on to next bite.