The Humble Programmer

A recent reddit post introduced me to a wonderfully lucid description of the problem of software engineering. Djikstra himself provides a particular prediction, based on well-organized reasoning, that software will become both cheaper and more reliable. While the prediction's fruition may be subject to debate, his arguments are as relevant today as they ever were.

The vision is that, well before the seventies have run to completion, we shall be able to design and implement the kind of systems that are now straining our programming ability, at the expense of only a few percent in man-years of what they cost us now, and that besides that, these systems will be virtually free of bugs.

These two improvements go hand in hand. In the latter respect software seems to be different from many other products, where as a rule a higher quality implies a higher price. Those who want really reliable software will discover that they must find means of avoiding the majority of bugs to start with, and as a result the programming process will become cheaper. 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. [Emphasis added.] In other words: both goals point to the same change.
...
I shall give you six arguments in support of ... the technical feasibility of the revolution which might take place [in the reliability of software]...

I summarize them here:

1. Avoidance of unmanageable tasks
   
2. Smaller solution spaces
   
3. Correctness by construction: Today a usual technique is to make a program and then to test it. But: program testing can be a very effective way to show the presence of bugs, but is hopelessly inadequate for showing their absence.
   
4. More abstraction
   
5. Better programming languages: the influence of the tool we are trying to use upon our own thinking habits.
   
6. Code reuse: the wider applicability of nicely factored solutions.
   

In the most interesting part of the essay, Djikstra disparages clever programming tricks, which he admits are often encouraged by the languages themselves.

The analysis of the influence that programming languages have on the thinking habits of its users, and the recognition that, by now, brainpower is by far our scarcest resource, they together give us a new collection of yardsticks for comparing the relative merits of various programming languages.

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. In the case of a well-known conversational programming language I have been told from various sides that as soon as a programming community is equipped with a terminal for it, a specific phenomenon occurs that even has a well-established name: it is called "the one-liners".

It takes one of two different forms: one programmer places a one-line program on the desk of another and either he proudly tells what it does and adds the question "Can you code this in less symbols?" —- as if this were of any conceptual relevance! -— or he just asks "Guess what it does!". From this observation we must conclude that this language as a tool is an open invitation for clever tricks; and while exactly this may be the explanation for some of its appeal, viz. to those who like to show how clever they are, I am sorry, but I must regard this as one of the most damning things that can be said about a programming language.

I don't know who scare me more: authors of excessively terse code, or blind advocates of particular programming paradigms (viz. OOP).

---

The full essay is The Humble Programmer, by Edsger W. Dijkstra.
More discussion is here.