It Began with Babbage (30 page)

On the other hand, like physical artifacts, a computer program is a dynamic thing; it consumes physical space and physical time. Most tantalizingly, a computer program, although a symbol structure, causes physical things to happen within a computer—much as thought causes bodily motion and bodily change in human beings. In other words, a computer program manifests
agency
.

Programs (or programming) is Janus faced in another way. On the one hand, programming is the means by which humans communicate with the machine, “telling” it what it must do; and the machine, in turn, must understand this communication and interpret the person's commands. On the other hand, programs are the means by which humans conceive computations, represent them to themselves, and communicate them to other human beings. The programmer then looks inward toward the physical computer and outward to herself and others like her.

As during the years leading up to and including the development of the ENIAC (see
Chapter 7
), as in conceiving the stored-program computer idea (see
Chapter 8
), the emergence of the computer program as a distinct kind of artifact—and programming as an activity—entailed an entanglement of several minds. For, as we can imagine, anyone who was developing a stored-program computer in that era would be forced to grapple with the problem of preparing a problem for solving on such machines.

In 1970, American computer scientist Donald Knuth (1938–) published a paper titled “Von Neumann's First Computer Program.”
⁴
Here, Knuth described the contents of a handwritten 1945 document that he believed was likely the earliest extant computer program for the stored-program digital computer.
⁵
In contrast to the usual discussions of computational problems, von Neumann's program was concerned with two classic
data processing
tasks (see
Chapter 3
, Sections V–VII): sorting data (numbers or alphabetic character strings such as names) into nondecreasing order and merging two sequences of sorted data into a single sorted file. IBM had its own special-purpose punched-card machines to perform these two tasks: the IBM 082 sorter and the IBM 085 collator (merger), respectively.
⁶
von Neumann was interested in whether the order code for the proposed EDVAC could work as well for nonnumeric computations (such as sorting and merging) as for numeric ones—and how efficiently, in terms of speed, it could do so. The availability of the IBM sorter, the most common machine for this task (on punched-card data) afforded him a standard of comparison.
⁷

Judging by the fragment of the original handwritten manuscript reproduced in Knuth's article, and Knuth's own commentary on it, von Neumann was not concerned with a language in which to communicate with others. It was, rather, a private notation. The program used quasinumeric symbols to refer to memory addresses (locations) and assigned actual addresses to individual instructions making up the program. He even made his program “relocatable” by designating an unspecified symbolic address “e” and assigning addresses to instructions relative to e.
⁸

The physicality of his program was evident; the amount of memory consumed by the program could be estimated. And, by making assumptions about the speed of execution of individual instructions, the execution time (in seconds) of the total program could be estimated.
⁹
Yet, the EDVAC (for which the program was intended) did not exist! von Neumann's program described a computational process for (in present-centered language) a virtual machine; in fact, what was still a hypothetical machine. There was no physical computer on which the program could be imposed that would “understand” or “interpret” the program and operate accordingly. The program was an abstract artifact in this sense. If von Neumann's sorting program of 1945 was indeed the earliest surviving instance of a program for a stored-program computer, the Janus-faced nature of programs-as-artifacts, their liminality, was manifest at its very inception.

Alluding to von Neumann's sorting program, Goldstine would remark that the problem of programming had not been scrutinized sufficiently up to that time,
¹⁰
and this was hardly surprising considering the embryonic stage of the field. There would soon be some attempt to rectify this situation, as Arthur Burks, Goldstine, and von Neumann went about preparing their lengthy report
Preliminary Discussion of the Logical Design of an Electronic Computing Instrument
in 1946 (see
Chapter 8
, Section XV).

Early that year, Goldstine and von Neumann developed a kind of graphical notation as an aid to help describe programs. They named this notation a
flow diagram
. Its objective was, as the name suggested, to express graphically the flow of control through the instructions as they were selected from memory and executed—a sense of
motion
through a computation. The flow diagram would also exhibit the status (contents) of variables at key points during the course of computation. Goldstine would recall that he was soon convinced of the
necessity
of such a notation in programming.
¹¹
Thus, the challenge in both expressing and understanding a flow diagram lay in the melding of the dynamic (the flow of control) with the static (the states of the variables at key points).

The point about necessity is worth noting. Concern for the preparation of a mathematical problem as a computation reach back to Ada Lovelace, as we have seen (see
Chapter 2
, Section VIII). However, now we see the emergence of a concern for a systematic notation for expressing computer programs. In Goldstine's flow diagram, we see the beginnings of another part of the stored-program computing paradigm: what would later be called
programming languages
.

In their 1947 memorandum titled
Planning and Coding Problems for an Electronic Computing Instrument
, Goldstine and von Neumann articulated explicitly at the very beginning the complexity of their problem.
¹²
A computer's “control organ” does not just move from one instruction to the next in a linear fashion. If this was the case, there would be no problem. The complexity lay in that the control organ has to “jump” every now and then, forward or backward, and sometimes it has to repeat sequences of instructions. In other words, the control organ must execute branches and iterations. And because in the IAS computer (for which this document was written)
¹³
the instructions in the Selectron-based main memory (see
Chapter 8
, Section XV) could be modified by other instructions, there was also the possibility that, in repeating a sequence of instructions, the instructions may have been altered.
¹⁴

The intricacies of programming were being put on the table, and the future programmer of the IAS computer was forewarned by Goldstine and von Neumann that the actual sequence of instructions executed in real time may not coincide with the ordering of the instructions in the program text. The latter is static; the former, dynamic. The point they were making, that the relation of the actual computer program to the mathematical procedure being programmed was not simply a matter of translation, was an important early
insight into the complexity of the programming activity. It was not simply a question of translating a piece of mathematical text into code.
¹⁵

In the literary realm, as every thoughtful translator of literary texts written in one language into another has recognized, translation is a creative process, for it entails not just a linguistic conversion, but a mapping from one culture to another. Literary translation has often been referred to as
transcreation
to acknowledge the creative aspect of this process.
¹⁶

The problem of “coding” (that is, programming) is also a problem of mapping from one culture to another—in the case of a solution to a mathematical problem, for example, mapping from mathematical culture to machine culture. Ever since Lovelace, those who have attempted to prepare problems for automatic computation have realized this, but it seems fair to say that Goldstine and von Neumann were probably the first to treat this problem of intercultural translation
as a problem in its own right
, and to bestow on it a huge measure of respect.

A program, a “coded instruction sequence,” itself
seems
a static entity—simply a sequence of instructions residing in specific locations of memory. This static appearance is misleading. What one must keep in mind is that a program “text” represents a
process
. And so the art of preparing a program should begin, as Goldstine and von Neumann advised, by planning the course of the
process
itself, its dynamic aspect, and
then
extract from this the actual instruction sequence as a “secondary” operation.
¹⁷
Here, Goldstine and von Neumann were grappling with an entirely new intellectual experience, and the insight it led them to was that one should first master the process (a dynamic entity), then program text (a static entity) can be extracted from the process.

Thus, the planning of a program should begin by depicting graphically the movement of the “control organ” through the instructions held in memory as the program is being executed. This graphic depiction (“schematic”) is the flow diagram for
the control organ
.
¹⁸

At the heart of why the program text does not mirror the process undertaken by the control organ is the phenomenon of repetition—the fact that the control organ may have to move several times through the same locations in memory to repeat a sequence of instructions.
¹⁹
The authors gave a litany of examples from mathematical situations of this sort. A repetitive process—or “iterative” process—would be best “visualized as a loop.” Goldstine and von Neumann called it an
inductive loop
. And although a linear sequence of operations with no iteration within it would be represented by a directed line, iterative (or inductive) loops would be symbolized by directed lines that closed in on themselves.

And so the language of the flow diagram unfolds. New symbols are introduced to represent how or when the control organ enters into a process and when it exists—to signify alternative pathways within a process, to specify conditions that cause the control organ to select one or the other of the alternative pathways, to describe actual arithmetic and other numeric operations performed during the course of the process.

The actual (arithmetic) operations performed during the course of a computational process are described by expressions and the destinations of the expression values—in present-centered language, by means of assignment statements. However, Goldstine's flow diagramming language also has something very interesting: “assertion boxes.”
²⁰

An assertion given in an assertion box inserted in a certain point in a flow diagram specifies certain relations are always satisfied whenever the control organ reaches that point.
²¹
This concept of assertions, describing relations between variables, such as
x + y = n
, or
x < z
, that
always
hold at certain points in the process is a way of stating that, in the midst of all the changes that occur during the course of a process, certain relations always hold—rather as the ancient Greek philosopher Parminedes insisted: behind all the appearance of change there is an unchanging constancy. As we will see later, this concept of static assertions placed within the representations of a dynamic process such as a computer program will become one of the linchpins in the development of (in present-centered language)
programming methodology
. Goldstine and von Neumann anticipated this later development, although it does not seem that they
influenced
those developments. They articulated a programming methodology of their own: programs (or coding, in their language) begins with the construction of flow diagrams.
²²

Their flow diagramming notation had a syntax. There were rules and principles that would have to be followed in drawing a flow diagram, and the reader of such a diagram would have to be conversant with the syntactic principles. In this sense, their flow diagram was more than a notational system; it was a language. Having first drawn the flow diagram showing the overall flow of control (the “dynamic” or “macroscopic” picture, in their language), the programmer then proceeds to code the instructions for the individual tasks shown in the “operation boxes” within a flow diagram. They called this the “static” or “microscopic” stage of programming. The main virtue here was that one could work on the coding of the individual operation boxes independent of one another.
²³
In contemporary language, their programming methodology advocated a blend of the hierarchical (macroscopic/microscopic) and the modular (independence of the individual boxes).

Figure 9.1
gives a flavor of how a Goldstine–von Neumann flow diagram might look. The boxes marked # signify assertions; the other boxes specify operations. At two points in the flow diagram alternate pathways are shown, with the path chosen depending on whether the pertinent expression is positive or negative. Iterations, possibly nested in other iterations, are also shown in the diagram.

If
Preliminary Discussion of the Logical Design of an Electronic Computing Instrument
by Burks and colleagues was a manuscript for the architecture of a stored-program computer,
Planning and Coding Problems for an Electronic Computing Instrument
was as surely a manifesto for a methodology of programming that computer. As we have seen, this methodology enfolded both the design of a language in which to describe programs as well as the process of translating a problem into a computation.