Lambda the Ultimate

In connection with the recent discussion concerning how people think about programming, I thought it might be worthwhile to revisit some of E. Dijkstra's writings on the subject.

From EWD854: The fruits of misunderstanding:

I think anthropomorphism is worst of all. I have now seen programs "trying to do things", "wanting to do things", "believing things to be true", "knowing things" etc. Don't be so naive as to believe that this use of language is harmless. It invites the programmer to identify himself with the execution of the program and almost forces upon him the use of operational semantics.

And now we have the fad of making all sorts of systems and their components "intelligent" or "smart". It often boils down to designing a woolly man-machine interface that makes the machine as unlike a computer as possible: the computer's greatest strength—the efficient embodiment of a formal system—has disguised at great cost.

Another analogy that did not work was pushed when the term "software engineering" was invented. The competent programmer's output can be viewed as that of an engineer: a non-trivial reliable mechanism but there the analogy stops...

From EWD1036: On the cruelty of really teaching computing science (html):

It is the most common way of trying to cope with novelty: by means of metaphors and analogies we try to link the new to the old, the novel to the familiar... Coping with radical novelty requires an orthogonal method... one has to approach the radical novelty with a blank mind, consciously refusing to try to link it with what is already familiar, because the familiar is hopelessly inadequate... Coming to grips with a radical novelty amounts ot creating and learning a new foreign tongue that can not be translated into one's mother tongue. (Any one who has learned quantum mechanics knows what I am talking about.)

A number of these phenomena have been bundled under the name "Software Engineering". As economics is known as "The Miserable Science", software engineering should be known as "The Doomed Discipline", doomed because it cannot even approach its goal since its goal is self-contradictory. Software engineering, of course, presents itself as another worthy cause, but that is eyewash [sic]: if you carefully read its literature and analyse what its devotees actually do, you will discover that software engineering has accepted as its charter "How to program if you cannot".

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... My next linguistical suggestion is mor rigorous. It is to fight the "if-this-guy-wants-to-talk-to-that-guy" syndrome: never refer to parts of programs or pieces of equipment in anthropomorphic terminology...

and finally there is the now-classic example (a domino-tiling problem) of why "operational reasoning is a tremendous waste of mental effort."