Edsger W. Dijkstra
- Quotes are arranged in chronological order
- 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 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.
- Dijkstra (1968) "A Case against the GO TO Statement" cited in: Bill Curtis (1981) Tutorial, human factors in software development. p. 109.
- Testing shows the presence, not the absence of bugs
- Dijkstra (1969) J.N. Buxton and B. Randell, eds, Software Engineering Techniques, April 1970, p. 16. Report on a conference sponsored by the NATO Science Committee, Rome, Italy, 27–31 October 1969. Possibly the earliest documented use of the famous quote.
- 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.
- Dijkstra (1970) "Notes On Structured Programming" (EWD249), Section 3 ("On The Reliability of Mechanisms"), p. 5.
- 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.
- Dijkstra (1970) "Notes On Structured Programming" (EWD249), Section 3 ("On The Reliability of Mechanisms"), p. 6.
- The art of programming is the art of organizing complexity, of mastering multitude and avoiding its bastard chaos as effectively as possible.
- Dijkstra (1970) "Notes On Structured Programming" (EWD249), Section 3 ("On The Reliability of Mechanisms"), p. 7.
- Program testing can be used to show the presence of bugs, but never to show their absence!
- Dijkstra (1970) "Notes On Structured Programming" (EWD249), Section 3 ("On The Reliability of Mechanisms"), corollary at the end.
- 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.
- Dijkstra (1972) The Humble Programmer (EWD340).
- On Our Inability To Do Much.
- Dijkstra (1972) "Structured Programming", Chapter title in O.J. Dahl, E.W. Dijkstra, and C.A.R. Hoare. Academic Press, 1972 ISBN 0122005503.
- 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.
- Dijkstra (1975) Comments at a Symposium (EWD 512).
- Several people have told me that my inability to suffer fools gladly is one of my main weaknesses.
- Dijkstra (1978) The pragmatic engineer versus the scientific designer (EWD 690).
- 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.
- Dijkstra (1979) My hopes of computing science (EWD 709).
- 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.
- Dijkstra (1979) My hopes of computing science (EWD 709).
The Humble Programmer (1972)
- 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!
- 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.
- 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.
How do we tell truths that might hurt? (1975)
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.
- Programming is one of the most difficult branches of applied mathematics; the poorer mathematicians had better remain pure mathematicians.
- 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.
- 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.
- Dijkstra (1984) Source: The threats to computing science (EWD898).
- The question of whether Machines Can Think... is about as relevant as the question of whether Submarines Can Swim.
- Dijkstra (1984) The threats to computing science (EWD898).
- 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.
- Dijkstra (1984) On the nature of Computing Science (EWD896).
- Probably I am very naive, but I also think I prefer to remain so, at least for the time being and perhaps for the rest of my life.
- 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.
- Dijkstra (1986) Visuals for BP's Venture Research Conference (EWD 963).
- The problems of the real world are primarily those you are left with when you refuse to apply their effective solutions.
- Dijkstra (1988) "On the cruelty of really teaching computing science (EWD1036).
- 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).
- Dijkstra (1993) "From my Life" (EWD 1166).
- 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.
- Dijkstra (1994) "The strengths of the academic enterprise" (EWD 1175).
- 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.
- Dijkstra (1995) "Introducing a course on calculi" (EWD 1213).
- 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.
- Dijkstra (1999) "Computing Science: Achievements and Challenges" (EWD 1284).
- 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.
- Dijkstra (2000) "Answers to questions from students of Software Engineering" (EWD 1305).
- It is not the task of the University to offer what society asks for, but to give what society needs.
- Dijkstra (2000), "Answers to questions from students of Software Engineering" (EWD 1305).
- 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
- 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!
- Dijkstra, "On the reliability of programs" (EWD 303).
Quotes about E.W. Dijkstra
- 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.
- You probably know that arrogance, in computer science, is measured in nanodijkstras.
- E. W. Dijkstra Archive - the manuscripts of Edsger W. Dijkstra