Top 109 Quotes & Sayings by Edsger Dijkstra

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.

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

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.

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

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

Aim for brevity while avoiding jargon.

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.

Mathematicians are like managers - they want improvement without change.

Perfecting oneself is as much unlearning as it is learning.

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.

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.

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.

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

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.

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.

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 ability of discerning high quality unavoidably implies the ability of identifying shortcomings.

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

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

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

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

Simplicity is prerequisite for reliability.

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.

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

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

There should be no such thing as boring mathematics.

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.

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

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

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.

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?

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

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

Teaching COBOL ought to be regarded as a criminal act.

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.

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

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.

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

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.

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.

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

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

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.

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?

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

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.

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

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.

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 abstraction is not to be vague, but to create a new semantic level in which one can be absolutely precise.

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.

Programming in Basic causes brain damage.

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

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

Brainpower is by far our scarcest resource.

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

The art of programming is the art of organizing complexity.

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.

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