Some Dijkstra Quotes

A few weeks ago I picked up the books A Discipline in Programming and Structured Programming. The first is by E. W. Dijkstra and the second includes a large section written by him. I became interested in these books after reading a few of Dijkstra’s other papers and about Donald Knuth’s great works. The computer science field could stand to have a bit more formalism in it and less hand-waving about “real-world” tools and methodologies.

Here are some quotes that I found especially good.

Recursive procedures/functions

The first quote is about recursive procedures. My friend and I had an argument over their efficiency when using the C programming language. I took the same view as Dijkstra though I did not put it in such words.

The argument against recursive procedures was always an efficiency argument: non-re-entrant code could be executed so much more efficiently. But with the advent of multiprogramming another need for flexible storage allocation has emerged. And if there are still machines in which the use of recursive routines is punished by too heavy a penalty, then I would venture the opinion that the structure of such a machine should now be called somewhat old-fashioned.

(Found on page 47-48 of Notes on Structured Programming)

In other words, we should build the machines we want to use if we are able to. We should not have to be stuck with old designs and Dijkstra talks about this in another paper of his, where he says that he hoped the computing industry would create new and better hardware. However, the industry insisted on backwards compatibility which is why newer machines still contain the flaws of previous machines.

On program modification as a manipulation of text and symbols

In this next quote, Dijkstra highlighted the dangers of regarding program modification as the manipulation of the symbols and text of a programming language.

(Both quotes found on page 60 of Notes on Structured Programming)

…In designing a program we have to consider many, many alternative programs and once our program is finished, we will have to change it (into one of the alternative ones). As long as programs are regarded as linear strings of basic symbols of a programming language and accordingly, program modification is treated as text manipulation on that level, then each program modification must be understood in the universe of all programs (right or wrong!) that can be written in that programming language. No wonder that program modification is then a most risky operation! The basic symbol is too small and meaningless a unit in terms of which to describe this.

This final quote again highlights the difference between the ideas behind a program and the surface of it expressed in some programming language.

…It was slightly overlooked, however, that by expressing structure via syntax, this structure is only given very indirectly, i.e. to be derived by means of a parsing algorithm to be applied to a linear sequence of basic symbols. This hurts if we realise that many a program modification leaves large portions of the structure unaffected, so that after painful re-parsing of the modified text the same structure re-emerges!

I find it slightly difficult to understand this when all we ever see of programs are the source code which is written in some programming language. We only ever really see the indirect structure. But when you look at a language like Lisp, or some Assembly language, there isn’t really a syntax there at all. You’re forced to discard the pervasive language metaphor.

Final Note

There are some more interesting ideas buried in the books and while I am exploring more of the history of the computing field, I have decided to give Donald’s Knuth’s idea of Literate Programming a chance. I am using it to complete a lab and an assignment for a class I’m taking and I have posted a sample conversion of a Haskell program.