Edsger Dijkstra Quotes - Page 3

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.

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

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.

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.

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

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

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

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.

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.

LISP has jokingly been described as "the most intelligent way to misuse a computer." I think that description is a great compliment because it transmits the full flavour of liberation: it has assisted a number of our most gifted fellow humans in thinking previously impossible thoughts.

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.

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.

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 effective exploitation of his powers of abstraction must be regarded as one of the most vital activities of a competent programmer.

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

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.

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

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.

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.

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.

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

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.

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.

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