Edsger Dijkstra quotes:

Many mathematicians derive part of their self-esteem by feeling themselves the proud heirs of a long tradition of rational thinking; I am afraid they idealize their cultural ancestors.

The traditional mathematician recognizes and appreciates mathematical elegance when he sees it. I propose to go one step further, and to consider elegance an essential ingredient of mathematics: if it is clumsy, it is not mathematics.

Computer science is no more about computers than astronomy is about telescopes.

Why has elegance found so little following? That is the reality of it. Elegance has the disadvantage, if that's what it is, that hard work is needed to achieve it and a good education to appreciate it.

Teaching to unsuspecting youngsters the effective use of formal methods is one of the joys of life because it is so extremely rewarding.

Program testing can be used to show the presence of bugs, but never to show their absence!

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.

Aim for brevity while avoiding jargon.

If debugging is the process of removing software bugs, then programming must be the process of putting them in.

Elegance is not a dispensable luxury but a factor that decides between success and failure.

Programming is one of the most difficult branches of applied mathematics; the poorer mathematicians had better remain pure mathematicians.

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.

The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense.

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.

Object-oriented programming is an exceptionally bad idea which could only have originated in California.

I mentioned the non-competitive spirit explicitly, because these days, excellence is a fashionable concept. But excellence is a competitive notion, and that is not what we are heading for: we are heading for perfection.

The question of whether computers can think is like the question of whether submarines can swim.

The students that, like the wild animal being prepared for its tricks in the circus called 'life', expects only training as sketched above, will be severely disappointed: by his standards he will learn next to nothing.

In passing I draw attention to another English expression which often occurs in Dutch texts: "the real world". In Dutch - and I am afraid not in Dutch alone - its usage is almost always a symptom of a violent anti-intellectualism.

Besides a mathematical inclination, an exceptionally good mastery of one's native tongue is the most vital asset of a competent programmer.

So-called "natural language" is wonderful for the purposes it was created for, such as to be rude in, to tell jokes in, to cheat or to make love in (and Theorists of Literary Criticism can even be content-free in it), but it is hopelessly inadequate when we have to deal unambiguously with situations of great intricacy, situations which unavoidably arise in such activities as legislation, arbitration, mathematics or programming.

Teaching COBOL ought to be regarded as a criminal act.

In this respect a program is like a poem: you cannot write a poem without writing it. Yet people talk about programming as if it were a production process and measure "programmer productivity" in terms of "number of lines of code produced". In so doing they book that number on the wrong side of the ledger: we should always refer to "the number of lines of code spent".

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.

The lurking suspicion that something could be simplified is the world's richest source of rewarding challenges.

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.

I now have had my foggy crystal ball for quite a long time. Its predictions are invariably gloomy and usually correct, but I am quite used to that and they won't keep me from giving you a few suggestions, even if it is merely an exercise in futility whose only effect is to make you feel guilty.

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.

If in physics there's something you don't understand, you can always hide behind the uncharted depths of nature. You can always blame God. You didn't make it so complex yourself. But if your program doesn't work, there is no one to hide behind. You cannot hide behind an obstinate nature. If it doesn't work, you've messed up.

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.

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.

APL is a mistake, carried through to perfection.

A most important, but also most elusive, aspect of any tool is its influence on the habits of those who train themselves in its use. If the tool is a programming language this influence is, whether we like it or not, an influence on our thinking habits.... A programming language is a tool that has profound influence on our thinking habits.

We shall do a much better programming job, provided that we approach the task with a full appreciation of its tremendous difficulty, provided that we stick to modest and elegant programming languages, provided that we respect the intrinsic limitations of the human mind and approach the task as Very Humble Programmers.

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 the problem set?

A programming language is a tool that has profound influence on our thinking habits.

Simplicity is prerequisite for reliability.

Computer science is no more about computers than astronomy is about telescopes

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.

The question of whether a computer can think is no more interesting than the question of whether a submarine can swim.

When building sand castles on the beach, we can ignore the waves but should watch the tide.

Simplicity and elegance are unpopular because they require hard work and discipline to achieve and education to be appreciated.

The competent programmer is fully aware of the limited size of his own skull. He therefore approaches his task with full humility, and avoids clever tricks like the plague.

... as a slow-witted human being I have a very small head and I had better learn to live with it and to respect my limitations and give them full credit, rather than to try to ignore them, for the latter vain effort will be punished by failure.

Please don't fall into the trap of believing that I am terribly dogmatical about [the goto 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 single trick, by a simple form of coding discipline!

Some consider the puzzles that are created by their omissions as spicy challenges, without which their texts would be boring; others shun clarity lest their work is considered trivial.

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.

Computer science is no more about computers than astronomy is about telescopes, biology is about microscopes or chemistry is about beakers and test tubes. Science is not about tools. It is about how we use them, and what we find out when we do.

Perfecting oneself is as much unlearning as it is learning.

John von Neumann draws attention to what seemed to him a contrast. He remarked that for simple mechanisms, it is often easier to describe how they work than what they do, while for more complicated mechanisms, it is usually the other way around.

I don't need to waste my time with a computer just because I am a computer scientist.

Raise your quality standards as high as you can live with, avoid wasting your time on routine problems, and always try to work as closely as possible at the boundary of your abilities. Do this, because it is the only way of discovering how that boundary should be moved forward.

There should be no such thing as boring mathematics.

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.

Mathematicians are like managers - they want improvement without change.

The ability of discerning high quality unavoidably implies the ability of identifying shortcomings.

Don't compete with me: firstly, I have more experience, and secondly, I have chosen the weapons.

The purpose of abstraction is not to be vague, but to create a new semantic level in which one can be absolutely precise.

Thanks to the greatly improved possibility of communication, we overrate its importance. Even stronger, we underrate the importance of isolation.

Thank goodness we don't have only serious problems, but ridiculous ones as well.

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?

It is a mistake to think that programmers wares are programs. Programmers have to produce trustworthy solutions and present it in the form of cogent arguments. Programs source code is just the accompanying material to which these arguments are to be applied to.

If we wish to count lines of code, we should not regard them as 'lines produced' but as 'lines spent.'

I would therefore like to posit that computing's central challenge, how not to make a mess of it, has not yet been met.

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.

We must be very careful when we give advice to younger people: sometimes they follow it!

Too few people recognize that the high technology so celebrated today is essentially a mathematical technology.

The computing scientist's main challenge is not to get confused by the complexities of his own making.

We are all shaped by the tools we use, in particular: the formalisms we use shape our thinking habits, for better or for worse, and that means that we have to be very careful in the choice of what we learn and teach, for unlearning is not really possible.

Production speed is severely slowed down if one works with half-time people who have other obligations as well. This is at least a factor of four; probably it is worse.

Testing shows the presence, not the absence of bugs.

Much of the excitement we get out of our work is that we don't really know what we are doing.

It used to be the program's purpose to instruct our computers; it became the computer's purpose to execute our programs.

...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.

[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.

The effective exploitation of his powers of abstraction must be regarded as one of the most vital activities of a competent programmer.

Beware of "the real world". A speaker's apeal to it is always an invitation not to challenge his tacit assumptions.

Beauty is our business.

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.

Experience does by no means automatically leads to wisdom and understanding.

It is not the task of the University to offer what society asks for, but to give what society needs.

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

The effort of using machines to mimic the human mind has always struck me as rather silly. I would rather use them to mimic something better.

Programming in Basic causes brain damage.

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).

The use of anthropomorphic terminology forces you linguistically to adopt an operational view. And it makes it practically impossible to argue about programs independently of their being executed.

Computer science has as much to do with computers as astronomy has to do with telescopes.

The problems of the real world are primarily those you are left with when you refuse to apply their effective solutions.

The prisoner falls in love with his chains.

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.

There is very little point in trying to urge the world to mend its ways as long as that world is still convinced that its ways are perfectly adequate.

In the software business there are many enterprises for which it is not clear that science can help them; that science should try is not clear either.

Mentally mutilated potential programmers beyond hope of regeneration.

Brainpower is by far our scarcest resource.

If there is one 'scientific' discovery I am proud of, it is the discovery of the habit of writing without publication in mind.

In their capacity as a tool, computers will be but a ripple on the surface of our culture. In their capacity as intellectual challenge, they are without precedent in the cultural history of mankind.

The art of programming is the art of organizing complexity.

...Simplifications have had a much greater long-range scientific impact than individual feats of ingenuity. The opportunity for simplification is very encouraging, because in all examples that come to mind the simple and elegant systems tend to be easier and faster to design and get right, more efficient in execution, and much more reliable than the more contrived contraptions that have to be debugged into some degree of acceptability....Simplicity and elegance are unpopular because they require hard work and discipline to achieve and education to be appreciated.

The tools we use have a profound and devious influence on our thinking habits, and therefore on our thinking abilities.

Progress is possible only if we train ourselves to think about programs without thinking of them as pieces of executable code.

Lisp has jokingly been called "the most intelligent way to misuse a computer". I think that description is 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.

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.

Yes, I share your concern: how to program well -though a teachable topic- is hardly taught. The situation is similar to that in mathematics, where the explicit curriculum is confined to mathematical results; how to do mathematics is something the student must absorb by osmosis, so to speak. One reason for preferring symbol-manipulating, calculating arguments is that their design is much better teachable than the design of verbal/pictorial arguments. Large-scale introduction of courses on such calculational methodology, however, would encounter unsurmoutable political problems.

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.

Several people have told me that my inability to suffer fools gladly is one of my main weaknesses.

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.

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.

PL/1, the fatal disease, belongs more to the problem set than to the solution set.