Jump to content

Edsger W. Dijkstra

From Wikiquote
(Redirected from Edsger Wybe Dijkstra)

Quotes by Dijkstra

[edit]
Quotes are arranged in chronological order

1960s

[edit]
  • 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.
  • Our intellectual powers are rather geared to master static relations and ... 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.

1970s

[edit]
  • A convincing demonstration of correctness being impossible as long as the mechanism is regarded as a black box, our only hope lies in not regarding the mechanism as a black box.
  • When we take the position that it is not only the programmer's responsibility to produce a correct program but also to demonstrate its correctness in a convincing manner, then the above remarks have a profound influence on the programmer's activity: the object he has to produce must be usefully structured.
  • The art of programming is the art of organizing complexity, of mastering multitude and avoiding its bastard chaos as effectively as possible.
  • Program testing can be used to show the presence of bugs, but never to show their absence!
  • The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility, and among other things he avoids clever tricks like the plague.
  • Another two years later, in 1957, I married and Dutch marriage rites require you to state your profession and I stated that I was a programmer. But the municipal authorities of the town of Amsterdam did not accept it on the grounds that there was no such profession. And, believe it or not, but under the heading "profession" my marriage act shows the ridiculous entry "theoretical physicist"!
  • Automatic computers have now been with us for a quarter of a century. They have had a great impact on our society in their capacity of tools, but in that capacity their influence will be but a ripple on the surface of our culture, compared with the much more profound influence they will have in their capacity of intellectual challenge without precedent in the cultural history of mankind.
  • After having programmed for some three years, I had a discussion with A. van Wijngaarden, who was then my boss at the Mathematical Center in Amsterdam, a discussion for which I shall remain grateful to him as long as I live. The point was that I was supposed to study theoretical physics at the University of Leiden simultaneously, and as I found the two activities harder and harder to combine, I had to make up my mind, either to stop programming and become a real, respectable theoretical physicist, or to carry my study of physics to a formal completion only, with a minimum of effort, and to become....., yes what? A programmer? But was that a respectable profession? For after all, what was programming? Where was the sound body of knowledge that could support it as an intellectually respectable discipline? I remember quite vividly how I envied my hardware colleagues, who, when asked about their professional competence, could at least point out that they knew everything about vacuum tubes, amplifiers and the rest, whereas I felt that, when faced with that question, I would stand empty-handed. Full of misgivings I knocked on van Wijngaarden's office door, asking him whether I could "speak to him for a moment"; when I left his office a number of hours later, I was another person. For after having listened to my problems patiently, he agreed that up till that moment there was not much of a programming discipline, but then he went on to explain quietly that automatic computers were here to stay, that we were just at the beginning and could not I be one of the persons called to make programming a respectable discipline in the years to come? This was a turning point in my life and I completed my study of physics formally as quickly as I could. One moral of the above story is, of course, that we must be very careful when we give advice to younger people; sometimes they follow it!
  • Please don't fall into the trap of believing that I am terribly dogmatic about [the go to statement]. I have the uncomfortable feeling that others are making a religion out of it, as if the conceptual problems of programming could be solved by a simple trick, by a simple form of coding discipline!
    • Dijkstra (1973) in personal communication to Donald Knuth, quoted in Knuth's "Structured Programming with go to Statements".
  • Don't blame me for the fact that competent programming, as I view it as an intellectual possibility, will be too difficult for "the average programmer" — you must not fall into the trap of rejecting a surgical technique because it is beyond the capabilities of the barber in his shop around the corner.
  • Are you quite sure that all those bells and whistles, all those wonderful facilities of your so-called "powerful" programming languages belong to the solution set rather than to the problem set?
  • Some people found error messages they couldn't ignore more annoying than wrong results, and, when judging the relative merits of programming languages, some still seem to equate "the ease of programming" with the ease of making undetected mistakes.
  • Write a paper promising salvation, make it a 'structured' something or a 'virtual' something, or 'abstract', 'distributed' or 'higher-order' or 'applicative' and you can almost be certain of having started a new cult.
  • For me, the first challenge for computing science is to discover how to maintain order in a finite, but very large, discrete universe that is intricately intertwined. And a second, but not less important challenge is how to mould what you have achieved in solving the first problem, into a teachable discipline: it does not suffice to hone your own intellect (that will join you in your grave), you must teach others how to hone theirs. The more you concentrate on these two challenges, the clearer you will see that they are only two sides of the same coin: teaching yourself is discovering what is teachable.

The Humble Programmer (1972)

[edit]

1972 Turing Award Lecture[1], Communications of the ACM 15 (10), October 1972: pp. 859–866.

  • As a result of a long sequence of coincidences I entered the programming profession officially on the first spring morning of 1952, and as far as I have been able to trace, I was the first Dutchman to do so in my country.
  • We must be very careful when we give advice to younger people: sometimes they follow it!
  • We must not forget that it is not our [computing scientists'] business to make programs, it is our business to design classes of computations that will display a desired behaviour.
  • The major cause [of the software crisis] is that the machines have become several orders of magnitude more powerful! To put it quite bluntly: as long as there were no machines, programming was no problem at all; when we had a few weak computers, programming became a mild problem, and now we have gigantic computers, programming has become an equally gigantic problem. In this sense the electronic industry has not solved a single problem, it has only created them, it has created the problem of using its products.
  • FORTRAN's tragic fate has been its wide acceptance, mentally chaining thousands and thousands of programmers to our past mistakes.
  • LISP has been jokingly described as "the most intelligent way to misuse a computer". I think that description a great compliment because it transmits the full flavor of liberation: it has assisted a number of our most gifted fellow humans in thinking previously impossible thoughts.
  • When FORTRAN has been called an infantile disorder, full PL/1, with its growth characteristics of a dangerous tumor, could turn out to be a fatal disease.
  • Using PL/1 must be like flying a plane with 7000 buttons, switches and handles to manipulate in the cockpit.
  • If you want more effective programmers, you will discover that they should not waste their time debugging, they should not introduce the bugs to start with.
  • Program testing can be a very effective way to show the presence of bugs, but it is hopelessly inadequate for showing their absence.
    • Compare more succinct phrasings cited above.
  • The effective exploitation of his powers of abstraction must be regarded as one of the most vital activities of a competent programmer.
  • The purpose of abstracting is not to be vague, but to create a new semantic level in which one can be absolutely precise.
    • Often misquoted as "The purpose of abstraction..."

How do we tell truths that might hurt? (1975)

[edit]

How do we tell truths that might hurt? (numbered EWD498, written 1975) was written as a series of aphorisms, and is the source of several popular quotations. It was also published in Selected Writings on Computing: A Personal Perspective.

  • The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense.
  • APL is a mistake, carried through to perfection. It is the language of the future for the programming techniques of the past: it creates a new generation of coding bums.
  • FORTRAN, 'the infantile disorder', by now nearly 20 years old, is hopelessly inadequate for whatever computer application you have in mind today: it is now too clumsy, too risky, and too expensive to use.
  • In the good old days physicists repeated each other's experiments, just to be sure. Today they stick to FORTRAN, so that they can share each other's programs, bugs included.
  • It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration.
  • Besides a mathematical inclination, an exceptionally good mastery of one's native tongue is the most vital asset of a competent programmer.
  • Simplicity is prerequisite for reliability.
  • We can found no scientific discipline, nor a hearty profession, on the technical mistakes of the Department of Defense and, mainly, one computer manufacturer.
  • About the use of language: it is impossible to sharpen a pencil with a blunt axe. It is equally vain to try to do it with ten blunt axes instead.

1980s

[edit]
  • Thank goodness we don't have only serious problems, but ridiculous ones as well.
    • Dijkstra (1982) "A Letter to My Old Friend Jonathan" (EWD475) p. 101 in Dijkstra, Edsger (1982). Selected Writings on Computing. Berlin: Springer-Verlag. ISBN 9780387906522. 
  • [Though computer science is a fairly new discipline, it is predominantly based on the Cartesian world view. As Edsgar W. Dijkstra has pointed out] A scientific discipline emerges with the - usually rather slow! - discovery of which aspects can be meaningfully 'studied in isolation for the sake of their own consistency.
    • Dijkstra (1982) as cited in: Douglas Schuler, Douglas Schuler Jonathan Jacky (1989) Directions and Implications of Advanced Computing, 1987. Vol 1, p. 84.
  • How do we convince people that in programming simplicity and clarity —in short: what mathematicians call "elegance"— are not a dispensable luxury, but a crucial matter that decides between success and failure?
    • Source: EWD648.
  • I think of the company advertising "Thought Processors" or the college pretending that learning BASIC suffices or at least helps, whereas the teaching of BASIC should be rated as a criminal offence: it mutilates the mind beyond recovery.
  • Simplicity is a great virtue but it requires hard work to achieve it and education to appreciate it. And to make matters worse: complexity sells better.
  • A confusion of even longer standing came from the fact that the unprepared included the electronic engineers that were supposed to design, build and maintain the machines. The job was actually beyond the electronic technology of the day, and, as a result, the question of how to get and keep the physical equipment more or less in working condition became in the early days the all-overriding concern. As a result, the topic became – primarily in the USA – prematurely known as 'computer science' – which, actually, is like referring to surgery as 'knife science' – and it was firmly implanted in people's minds that computing science is about machines and their peripheral equipment. Quod non [Latin: "Which is not true"]. We now know that electronic technology has no more to contribute to computing than the physical equipment. We now know that programmable computer is no more and no less than an extremely handy device for realizing any conceivable mechanism without changing a single wire, and that the core challenge for computing science is hence a conceptual one, viz., what (abstract) mechanisms we can conceive without getting lost in the complexities of our own making.
  • When we had no computers, we had no programming problem either. When we had a few computers, we had a mild programming problem. Confronted with machines a million times as powerful, we are faced with a gigantic programming problem.
  • My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger.
  • As economics is known as "The Miserable Science", software engineering should be known as "The Doomed Discipline", doomed because it cannot even approach its goal since its goal is self-contradictory. (...) Software engineering has accepted as its charter "How to program if you cannot.

1990s

[edit]
A picture may be worth a thousand words, a formula is worth a thousand pictures.
  • When I came back from Munich, it was September, and I was Professor of Mathematics at the Eindhoven University of Technology. Later I learned that I had been the Department's third choice, after two numerical analysts had turned the invitation down; the decision to invite me had not been an easy one, on the one hand because I had not really studied mathematics, and on the other hand because of my sandals, my beard and my "arrogance" (whatever that may be).
  • In the wake of the Cultural Revolution and now of the recession I observe a mounting pressure to co-operate and to promote "teamwork". For its anti-individualistic streak, such a drive is of course highly suspect; some people may not be so sensitive to it, but having seen the Hitlerjugend in action suffices for the rest of your life to be very wary of "team spirit". Very.
  • I mean, if 10 years from now, when you are doing something quick and dirty, you suddenly visualize that I am looking over your shoulders and say to yourself "Dijkstra would not have liked this", well, that would be enough immortality for me.
  • A picture may be worth a thousand words, a formula is worth a thousand pictures.
    • Dijkstra (EWD1239: A first exploration of effective reasoning)
  • It is time to unmask the computing community as a Secret Society for the Creation and Preservation of Artificial Complexity.
  • Elegance is not a dispensable luxury but a quality that decides between success and failure.
  • Industry suffers from the managerial dogma that for the sake of stability and continuity, the company should be independent of the competence of individual employees. Hence industry rejects any methodological proposal that can be viewed as making intellectual demands on its work force. Since in the US the influence of industry is more pervasive than elsewhere, the above dogma hurts American computing science most. The moral of this sad part of the story is that as long as computing science is not allowed to save the computer industry, we had better see to it that the computer industry does not kill computing science.
  • May, in spite of all distractions generated by technology, all of you succeed in turning information into knowledge, knowledge into understanding, and understanding into wisdom.
    • Dijkstra (1998) [2]

2000s

[edit]
  • The required techniques of effective reasoning are pretty formal, but as long as programming is done by people that don't master them, the software crisis will remain with us and will be considered an incurable disease. And you know what incurable diseases do: they invite the quacks and charlatans in, who in this case take the form of Software Engineering gurus.
  • There are very different programming styles. I tend to see them as Mozart versus Beethoven. When Mozart started to write, the composition was finished. He wrote the manuscript and it was 'aus einem Guss' (from one cast). In beautiful handwriting, too. Beethoven was a doubter and a struggler who started writing before he finished the composition and then glued corrections onto the page. In one place he did this nine times. When they peeled them, the last version proved identical to the first one.
    • Dijkstra (2001) Source: Denken als discipline, a program from Dutch public TV broadcaster VPRO from April 10th, 2001 about Dijkstra
  • What is the shortest way to travel from Rotterdam to Groningen, in general: from given city to given city. It is the algorithm for the shortest path, which I designed in about twenty minutes. One morning I was shopping in Amsterdam with my young fiancée, and tired, we sat down on the café terrace to drink a cup of coffee and I was just thinking about whether I could do this, and I then designed the algorithm for the shortest path. As I said, it was a twenty-minute invention. In fact, it was published in '59, three years late. The publication is still readable, it is, in fact, quite nice. One of the reasons that it is so nice was that I designed it without pencil and paper. I learned later that one of the advantages of designing without pencil and paper is that you are almost forced to avoid all avoidable complexities. Eventually that algorithm became, to my great amazement, one of the cornerstones of my fame.
    • Dijkstra (2001), in an interview with Philip L. Frana. (OH 330; Communications of the ACM 53(8):41–47)

Unknown date

[edit]
  • In short, I suggest that the programmer should continue to understand what he is doing, that his growing product remains firmly within his intellectual grip. It is my sad experience that this suggestion is repulsive to the average experienced programmer, who clearly derives a major part of his professional excitement from not quite understanding what he is doing. In this streamlined age, one of our most undernourished psychological needs is the craving for Black Magic and apparently the automatic computer can satisfy this need for the professional software engineer, who is secretly enthralled by the gigantic risks he takes in his daring irresponsibility. For his frustrations I have no remedy......
  • This is generally true: any sizeable piece of program, or even a complete program package, is only a useful tool that can be used in a reliable fashion, provided that the documentation pertinent for the user is much shorter than the program text. If any machine or system requires a very thick manual, its usefulness becomes for that very circumstance subject to doubt!

Quotes about Dijkstra

[edit]
  • The precious gift that this Turing Award acknowledges is Dijkstra's style: his approach to programming as a high, intellectual challenge; his eloquent insistence and practical demonstration that programs should be composed correct, not just debugged into correctness; and his illuminating perception of problems at the foundations of program design.
    • M.D. Mcllroy (1972) at the presentation of the lecture on August 14, 1972, at the ACM Annual Conference in Boston, cited in E.G. Dijkstra (1972) "The Humble Programmer". 1972 ACM Turing Award Lecture. in: Communications of the ACM 15 (10), October 1972: pp. 859–866.
  • A revolution is taking place in the way we write programs and teach programming, because we are beginning to understand the associated mental processes more deeply. It is impossible to read the recent [E. W. Dijkstra, O.-J. Dahl, and C. A. R. Hoare] book Structured Programming, without having it change your life. The reason for this revolution and its future prospects have been aptly described by E.W. Dijkstra in his 1972 Turing Award Lecture, The Humble Programmer.
    • Donald Knuth (1974), in Structured Programming with Go To Statements. (Computing Surveys 6 (4): 261–301).
  • The working vocabulary of programmers everywhere is studded with words originated or forcefully promulgated by E. W. Dijkstra—display, deadly embrace, semaphore, go-to-less programming, structured programming. But his influence on programming is more pervasive than any glossary can possibly indicate.
    • David Gries (1978), in Programming Methodology: A Collection of Articles by Members of IFIP WG2.3 (New York: Springer Verlag), p. 7.
  • Edsger W. Dijkstra's 1969 "Structured Programming" article precipitated a decade of intense focus on programming techniques that has fundamentally altered human expectations and achievements in software development. Before this decade of intense focus, programming was regarded as a private, puzzle-solving activity of writing computer instructions to work as a program. After this decade, programming could be regarded as a public, mathematics-based activity of restructuring specifications into programs. Before, the challenge was in getting programs to run at all, and then in getting them further debugged to do the right things. After, programs could be expected to both run and do the right things with little or no debugging. Before, it was common wisdom that no sizable program could be error-free. After, many sizable programs have run a year or more with no errors detected. These expectations and achievements are not universal because of the inertia of industrial practices. But they are well-enough established to herald fundamental change in software development.
    • Harlan Mills (1986). Structured Programming: Retrospect and Prospect. (IEEE Software 3(6): 58-66, November 1986)
  • The difference between a computer programmer and a computer scientist is a job-title thing. Edsgar Dijkstra wants proudly to be called a "computer programmer," although he hasn't touched a computer now for some years. (...) His great strength is that he is uncompromising. It would make him physically ill to think of programming in C++.
    • Donald Knuth (1996), in an interview by Jack Woehr of Dr. Dobb's Journal.
  • You probably know that arrogance, in computer science, is measured in nanodijkstras.
  • ...I also discovered books of two great computer scientists from whose work I learned the scientific foundation of my trade: Donald Knuth and Edsger Dijkstra. Knuth taught me the answers. Dijkstra taught me the questions. Time and time again I come back to their works for new insights.
    • Alexander Stepanov (1997), in an interview with Graziano Lo Russo of Edizioni Infomedia srl.
  • The first classic is one of the great works in computer programming: E. W. Dijkstra, Cooperating Sequential Processes (1965). Here Dijkstra lays the conceptual foundation for abstract concurrent programming.
    • Per Brinch Hansen, in The Origin of Concurrent Programming: From Semaphores to Remote Procedure Calls (Springer, 2002)
  • Most experienced IT professionals will agree that developing and adhering to a standard architecture is key to the success of large-scale software development. Computer pioneer Edsger Dijkstra validated this notion when he developed THE operating system in 1968. Since then, layered architectures have proved their viability in technological domains, such as hardware and networking. Layering has proved itself in the operating system domain; however, the same benefits are available when applied to e-commerce or to thin client–oriented applications. Layered architectures have become essential in supporting the iterative development process by promoting reusability, scalability, and maintainability.
    • Kyle Brown, Gary Craig, Greg Hester et al. (2003). Enterprise Java Programming with IBM WebSphere, 2nd Edition (IBM Press), p. 5
  • Edsger Dijkstra, one of the giants of our field and a passionate believer in the mathematical view of programs and programming (...) Over the previous quarter-century, he had formulated many of the great intellectual challenges of the field as programming—the goto statement, structured programming, concurrent processes, semaphores, deadlocks, recursive programming in Algol, and deriving correct programs.
    • Peter J. Denning, former ACM president, in The Field of Programmers Myth (Communications of the ACM, 47 (7) pp. 15-20, 2004)
  • Of great influence to Pascal was Structured Programming, put forth by E. W. Dijkstra. This method of proceeding in a design would obliviously be greatly encouraged by the use of a Structured Language, a language with a set of constructs that could freely be combined and nested. The textual structure of a program should directly reflect its flow of control.
    • Niklaus Wirth, in Impact of Software Engineering Research on Modern Programming Languages (ACM Transactions on Software Engineering and Methodology, Vol. 14, No. 4, October 2005, p. 431-477)
  • In 1965 Dijkstra wrote his famous Notes on Structured Programming and declared programming as a discipline in contrast to a craft. Also in 1965 Hoare published an important paper about data structuring. These ideas had a profound influence on new programming language, in particular Pascal. Languages are the vehicles in which these ideas were to be expressed. Structured programming became supported by a structured programming language.
    • Niklaus Wirth, in A Brief History of Software Engineering (IEEE Annals of the History of Computing, vol.30, no. 3, July–September 2008, p. 32-39)
  • The notion of the concurrent program as a means for writing parallel programs without regard for the underlying hardware was first introduced by Edsger Dijkstra (1968). Moti Ben-Ari (1982) elegantly summed up Dijkstra's idea in three sentences: 'Concurrent programming is the name given to programming notation and techniques for expressing potential parallelism and solving the resulting synchronization and communication problems. Implementation of parallelism is a topic in computer systems (hardware and software) that is essentially independent of concurrent programming. Concurrent programming is important because it provides an abstract setting in which to study parallelism without getting bogged down in the implementation details.'
    • John W. McCormick, Frank Singhoff, Jérôme Hugues (2011). Building Parallel, Embedded, and Real-Time Applications with Ada (Cambridge University Press), p. 5
  • The revolution in views of programming started by Dijkstra's iconoclasm led to a movement known as structured programming, which advocated a systematic, rational approach to program construction. Structured programming is the basis for all that has been done since in programming methodology, including object-oriented programming. As the first book on the topic [Structured Programming by Dijkstra, Ole-Johan Dahl, and Tony Hoare] shows, structured programming is about much more than control structures and the goto. Its principal message is that programming should be considered a scientific discipline based on mathematical rigor.
    • Bertrand Meyer (2009), in Touch of Class: Learning to Program Well with Objects and Contracts. (Springer), p. 188.
  • Since the early work of E.W. Dijkstra (1965), who introduced the mutual exclusion problem, the concept of a process, the semaphore object, the notion of a weakest precondition, and guarded commands (among many other contributions), synchronization is no longer a catalog of tricks but a domain of computing science with its own concepts, mechanisms, and techniques whose results can be applied in many domains. This means that process synchronization has to be a major topic of any computer science curriculum.
    • Michel Raynal (2013), in Concurrent Programming: Algorithms, Principles, and Foundations (Springer), p. vi.
  • Although Dijkstra will always be remembered for structured programming, and for his style and approach, he also invented many other of the standard ideas of programming. If you are struggling with multi-threaded programming you may have encountered the semaphore, and the idea of the "deadly embrace". These, and more, are the result of Dijkstra's work on concurrent programming. He showed how this particularly difficult area of programming could be made relatively safe.
    • Mike James (2013), in Edsger Dijkstra - The Poetry of Programming, by website i-programmer.info
  • While concurrent program execution had been considered for years, the computer science of concurrency began with Edsger Dijkstra's seminal 1965 paper that introduced the mutual exclusion problem. (...) The first scientific examination of fault tolerance was Dijkstra's seminal 1974 paper on self-stabilization. (...) The ensuing decades have seen a huge growth of interest in concurrency—particularly in distributed systems. Looking back at the origins of the field, what stands out is the fundamental role played by Edsger Dijkstra, to whom this history is dedicated.
    • Leslie Lamport, in Turing Lecture: The Computer Science of Concurrency: The Early Years (Communications of the ACM, Vol. 58 No. 6, June 2015)
  • We generally trace the idea of building computer systems in layers back to a 1967 paper that the Dutch computer scientist Edsger Dijkstra gave to a joint IEEE Computer Society/ACM conference. Prior to this paper, engineers had struggled with the problem of how to organize software. If you look at early examples of programs, and you can find many in the electronic library of the Computer Society, you will find that most code of that era is complicated, difficult to read, hard to modify, and challenging to reuse. In his 1967 paper, Dijkstra described how software could be constructed in layers and gave an example of a simple operating system that used five layers. He admitted that this system might not be a realistic test of his ideas but he argued that the "larger the project, the more essential the structuring!" The idea of using layers to control complexity has become a mainstay of software architecture. We see it in many forms and apply it to many problems. We see it in the hierarchy of classes in object-oriented programming and in the structure of Service-Oriented Architecture (SOA). SOA is a relatively recent application of layering in computer science. It was articulated in 2007 as a means of controlling complexity in business systems, especially distributed systems that make substantial use of the Internet. Like Dijkstra's plan for system development, its layering system is called the SOA Solution Stack or S3. The S3's nine layers are: 1) operational systems, 2) service components, 3) services, 4) business processes, 5) consumer actions, 6) system integration, 7) quality control and assurance, 8) information architecture, and 9) system governance and policies.


Disputed

[edit]
  • Computer Science is no more about computers than astronomy is about telescopes.


Misattributed

[edit]
  • Go To statement considered harmful
    • Dijkstra sent a paper to Communications of the ACM under the title of "A Case against the GO TO Statement" (EWD215, PDF here). However the editor Niklaus Wirth decided to publish it as a letter to the editor to speed up publication. Wirth changed the title to "The goto statement considered harmful". Dijkstra explains it himself in EWD1308 (see near the end of the article).
[edit]
Wikipedia
Wikipedia
Wikipedia has an article about:
Retrieved from "https://en.wikiquote.org/w/index.php?title=Edsger_W._Dijkstra&oldid=3614693"