Computers versus programs

A strong influence on how I think about programming is a 1971 book by Edsger Dijkstra named A Discipline of Programming. Most of this book is a series of elegant solutions to simple problems, but parts of it are philosophical essays, some of which have stuck with me for the more than 35 years since I've read them.

One of these essays addresses the notion that a program is something that we use to tell a computer what to do. Dijkstra emphatically rejected that notion, saying instead that he considered a computer to be a device for executing our programs.

On the surface, these two ideas may seem equivalent. However, a closer look reveals that Dijkstra has introduced a new level of abstraction into the discussion, and this abstraction profoundly affects how we program.

This abstraction concerns the language in which we program--the rules of the game, as it were. If the purpose of a program is to instruct a machine, then the actual behavior of the machine defines the nature of our instructions. If, instead, the purpose of the machine is to execute our programs, then there is the possibility that the machine might fail to comply with the rules that we use for writing our programs, and in that case we are justified in saying that the machine is broken and the manufacturer should fix it.

Around the time that Dijkstra wrote his book, something happened that underscored his point--even though I did not realize the connection until this morning. I had a friend who worked in the data center of a large media company, and part of her job was to decide whether to accept or reject the first model of a brand-new mainframe. She and her colleagues ran all kinds of tests on this machine, and eventually uncovered a problem: When a subroutine-call instruction happened to be located at the very end of a memory page, the return address would not be the address of the first byte of the next page, as one would expect--instead, it would be the first byte of the current page.

As you would expect, this problem caused all kinds of strange failures. Moreover, those failures were quite rare, as they happened only in these very specific circumstances.

My friend had no trouble dealing with this situation: She rejected the machine and told the manufacturer to bring it back when it worked. Part of what gave her the authority to do this was that the manufacturer had written a document that described how the machine was expected to behave. In effect, this document was the rule book that programmers were supposed to use to program this machine, and when the machine didn't follow the rules, it was the machine, not the rules, that were at fault.

This discussion may seem obvious. However, even to this day it is surprising how often programmers have to change their programs to work around undocument behavioral bugs in the systems on which they depend.

Posted by Andrew Koenig at 11:25 AM  Permalink