The Humble Programmer

2026-11-05

Tucked away in my notes I found Dijkstra’s acceptance speech at ACM Turing Award in 1972. For a short biography and to better understand the man who, by his own admission, was the first Dutch programmer, you can check The Man Who Carried Computer Science On His Shoulders.

Reading it through the lenses of more than half a century, it makes for a rather bleak picture. Here are some random thoughts:

…modern machinery is basically more difficult to handle than the old machinery. Firstly, we have got the I/O interrupts, occurring at unpredictable and irreproducible moments; compared with the old sequential machine that pretended to be a fully deterministic automaton, this has been a dramatic change and many a systems programmer’s grey hair bears witness to the fact that we should not talk lightly about the logical problems created by that feature. Secondly, we have got machines equipped with multi-level stores, presenting us problems of management strategy that, in spite of the extensive literature on the subject, still remain rather elusive.

Still so true! As I’ve always said: “Only beginners believe computers are deterministic machines”.

And if your definition of price is the price to be paid for the hardware, little will prevent you from ending up with a design that is terribly hard to program for: for instance the order code might be such as to enforce, either upon the programmer or upon the system, early binding decisions presenting conflicts that really cannot be resolved. And to a large extent these unpleasant possibilities seem to have become reality.

I’m wondering what Dijkstra was thinking in the ‘90-es when microprocessors with limited address space showed up, and you had to fiddle with segment registers and dynamic linking – the plague that hasn’t left us yet.

The sooner we can forget that FORTRAN has ever existed, the better, for as a vehicle of thought it is no longer adequate: it wastes our brainpower, is too risky and therefore too expensive to use.

No, not even 50 years latter, FORTRAN has not disappeared, and neither has the other monstrosity of the ‘60es, COBOL. In 1977 FORTRAN got a new coat and still many in the scientific community say that it is a very “efficient”.

Using PL/1 must be like flying a plane with 7000 buttons, switches and handles to manipulate in the cockpit. I absolutely fail to see how we can keep our growing programs firmly within our intellectual grip when by its sheer baroqueness the programming language —our basic tool, mind you!— already escapes our intellectual control.

Fortunately, PL/I was not successful and it is now almost dead. Its death, however, doesn’t seem to have taught us the dangers of baroqueness and C++ is an example. Having started as a C preprocessor, sometimes called “C with objects”, it was grown and continues to grow into a monster with a more and more difficult syntax and heaps of functionality added into the “standard library’. Dijkstra continues:

And if I have to describe the influence PL/1 can have on its users, the closest metaphor that comes to my mind is that of a drug. I remember from a symposium on higher level programming language a lecture given in defense of PL/1 by a man who described himself as one of its devoted users. But within a one-hour lecture in praise of PL/1. he managed to ask for the addition of about fifty new “features”, little supposing that the main source of his problems could very well be that it contained already far too many “features”. The speaker displayed all the depressing symptoms of addiction, reduced as he was to the state of mental stagnation in which he could only ask for more, more, more…

Yes, C++20, C++23, C++26…

Looking to the future, Dijkstra turns out to be an irremediable optimist. Form the very beginning he says: “But there is no point in making mistakes unless thereafter we are able to learn from them”. If only!

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.

There are two word to cancel this vision: vibe coding. The man who argued for building the proof of correctness at the same time as the program itself would probably be horrified to see us leaving a stochastic model to generate the program. What could go wrong?

Dijkstra’s paper is written not long after the realization that there is a “software crisis” (the term originated at a conference in 1968) and, optimistically, Dijkstra believes that the solution to this crisis is restricting ourselves to “intellectually manageable programs”.

…the class of intellectually manageable programs is still sufficiently rich to contain many very realistic programs for any problem capable of algorithmic solution. We must not forget that it is not our business to make programs, it is our business to design classes of computations that will display a desired behavior.

Given today’s ubiquity of software, I find his perspective coming somewhat from an ivory tower: the world didn’t have the patience to wait for perfect, formally proofed programs; we went ahead and built good-enough programs and suffered the consequences.

In the series of 6 arguments that Dijkstra brings to support his thesis, he comes up with one of his best-known quotes:

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. The only effective way to raise the confidence level of a program significantly is to give a convincing proof of its correctness.

The many security breaches that have occurred over the years proof positive of this affirmation.

The following anecdote left me wondering what language Dijkstra had in mind:

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 suspected he was talking of APL, and indeed I found it quoted on an APL Wiki.

Returning to language complexity, his preferences are clear:

Another lesson we should have learned from the recent past is that the development of “richer” or “more powerful” programming languages was a mistake in the sense that these baroque monstrosities, these conglomerations of idiosyncrasies, are really unmanageable, both mechanically and mentally. I see a great future for very systematic and very modest programming languages.

Clearly, language design hasn’t evolved in the direction envisioned by Dijkstra. Object-oriented programming that appeared a few years later, made new languages more baroque and even simpler languages like C turned into behemoths like C++. I found a quote, attributed to Dijkstra that summarizes his opinions: “Object-oriented programming is an exceptionally bad idea which could only have originated in California.”

The last argument in favor of “intellectually manageable programs” seems also the path that Dijkstra envisions for such goal: the concept of hierarchy. He asserts that systematic decomposition or factoring of problems will allow us to manage greater and greater levels of abstraction. Looking back over 50 years, I can see some of that taking place, but not in the timeframe of 10-15 years envisioned by Dijkstra. We have almost lost sight of assembly languages and regard them almost as domain of hardware folks, C is accepted as a common “low level language”, but higher levels of programming languages have not become so entrenched. We still oscillate between Rust, C++, Python, Java, etc.

To conclude these feeble remarks, let me get back to the beginning of the talk:

I stated that I was a programmer.

Having been called “software engineer”, “programmer”, “developer”, “computer systems analyst”, and never knowing exactly what I am, I think that if Dijkstra calls himself a programmer, I can call myself a programmer too. And following Dijkstra’s parting advice, I’ll try to be a “Very Humble Programmer”.