Dijkstra Paper

Topics: Programming language, Edsger W. Dijkstra, Communications of the ACM Pages: 5 (1691 words) Published: December 2, 2012
(A Look Back at) Go To Statement Considered Harmful
Edsger Dijkstra wrote a Letter to the Editor of Communications in 1968, criticizing the excessive use of the go to statement in programming languages. Instead, he encouraged his fellow computer scientists to consider structured programming. The letter, originally entitled “A Case Against the Goto Statement,” was published in the March 1968 issue under the headline “Go To Statement Considered Harmful.” It would become the most legendary CACM “Letter” of all time; “Considered Harmful” would develop into an iconic catch-all. Dijkstra’s comments sparked an editorial debate that spanned these pages for over 20 years. In honor of the occasion, we republish here the original letter that started it all. Editor: For a number of years I have been familiar with the observation that the quality of programmers is a decreasing function of the density of go to statements in the programs they produce. More recently I discovered why the use of the go to statement has such disastrous effects, and I became convinced that the go to statement should be abolished from all “higher level” programming languages (i.e. everything except, perhaps, plain machine code). At that time I did not attach too much importance to this discovery; I now submit my considerations for publication because in very recent discussions in which the subject turned up, I have been urged to do so. My first remark is that, although the programmer’s activity ends when he has constructed a correct program, the process taking place under control of his program is the true subject matter of his activity, for it is this process that has to accomplish the desired effect; it is this process that in its dynamic behavior has to satisfy the desired specifications. Yet, once the program has been made, the “making” of the corresponding process is delegated to the machine. My second remark is that our intellectual powers are rather geared to master static relations and that our powers to visualize processes evolving in time are relatively poorly developed. For that reason we should do (as wise programmers aware of our limitations) our utmost to shorten the conceptual gap between the static program and the dynamic process, to make the correspondence between the program (spread out in text space) and the process (spread out in time) as trivial as possible. Let us now consider how we can characterize the progress of a process. (You may think about this question in a very concrete manner: suppose that a process, considered as a time succession of actions, is stopped after an arbitrary action, what data do we have to fix in order that we can redo the process until the very same point?) If the program text is a pure concatenation of, say, assignment statements (for the purpose of this discussion regarded as the descriptions of single actions) it is sufficient to point in the program text to a point between two successive action descriptions. (In the absence of go to statements I can permit myself the syntactic ambiguity in the last three words of the previous sentence: if we parse them as “successive (action descriptions) “we mean successive in text space; if we parse as “(successive action) descriptions” we mean successive in time.) Let us 7


COMMUNICATIONS OF THE ACM January 2008/Vol. 51, No. 1

call such a pointer to a suitable place in the text a “textual index.” When we include conditional clauses (if B then A), alternative clauses (if B then A1 else A2), choice clauses as introduced by C.A.R. Hoare (case[i] of (A1, A2, ... , An)), or conditional expressions as introduced by J. McCarthy (B1__ >E1, B2 __ E2, ... , Bn __ > > En), the fact remains that the progress of the process remains characterized by a single textual index. As soon as we include in our language procedures we must admit that a single textual index is no longer sufficient. In the case that a textual index points to the interior of a procedure...

References: 1. Wirth, Niklaus, and Hoare, C.A.R. A contribution to the development of ALGOL. Comm. ACM 9 (June 1966), 413–432. 2. Bohn, Corrado, and Jacopini, Guiseppe. Flow Diagrams, Turing machines and languages with only two formation rules. Comm. ACM 9 (May 1966) 366–371.
Coming Next Month in
Alternate Reality Gaming IT Diffusion in Developing Countries Are People Biased in their Use of Search Engines? The Factors that Affect Knowledge-Sharing Behavior Alternative Scenarios to the “Banner” Years Municipal Broadband Wireless Networks The Myths and Truths about Wireless Security Managing Large Collections of Data Mining Models Women and Men in IT: Alike or Different?
EDSGER W. DIJKSTRA Technological University Eindhoven, The Netherlands Communications of the ACM March 1968, Vol. 11, No. 3, pg 147
COMMUNICATIONS OF THE ACM January 2008/Vol. 51, No. 1
Continue Reading

Please join StudyMode to read the full document

You May Also Find These Documents Helpful

  • School Papers
  • Enzymes and Paper
  • General Paper
  • Banana Paper
  • Paper Flower
  • Ancient Paper
  • Paper Charcoal
  • Recycling Paper

Become a StudyMode Member

Sign Up - It's Free