Edsger W. Dijkstra

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

Simplicity is prerequisite for reliability.

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

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

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

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

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?

Testing can be a very effective way to show the presence of bugs, but it is hopelessly inadequate for showing their absence.

We could, for instance, begin with cleaning up our language by no longer calling a bug a bug but by calling it an error. It is much more honest because it squarely puts the blame where it belongs, viz. with the programmer who made the error. The animistic metaphor of the bug that maliciously sneaked in while the programmer was not looking is intellectually dishonest as it disguises that the error is the programmer’s own creation. The nice thing of this simple change of vocabulary is that it has such a profound effect: while, before, a program with only one bug used to be “almost correct”, afterwards a program with an error is just “wrong”.

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

LISP has assisted a number of our most gifted fellow humans in thinking previously impossible thoughts.

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.

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

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.

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.

A picture may be worth a thousand words, a formula is worth a thousand pictures.

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.

Don’t blame me for the fact that competent programming 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.

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

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

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

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