- A Science of Operations: Machines, Logic and the Invention of Programming
From the perspective of a contemporary computer scientist or programmer, the connections between programming languages and logic seem to be strong. However, how strong were they really during early developments? How did individual decisions influence this connection? Taking the reader back to 19th century England, Mark Priestley's A Science of Operations narrates the story of communicating the problem to the machine from Babbage's time until the late 20th century—just before object oriented programming overtook structured programming.
Priestley begins by putting the mechanization of various processes into a broad cultural context, starting with Charles Babbage's efforts. He draws Menabrea's and Ada Augusta's mathematical (the user's) view of the engine to the readers' attention as opposed to Babbage's mechanical (the constructor's) view by painstakingly analyzing the original writings of Babbage, Lovelace, and Menabrea.
Connections between automation and logic could be developed from either side. However, as the analysis of the programming of early relay machines such as ENIAC and the Bell Labs relay machine shows, by and large, the engineers were unaware of the developments in logic. Rather, the construction of the machines copied the practices of manual computation. Logicians on the other hand, in particular von Neumann and Wilkes, were interested in the practical aspects of computation.
From the 1930s through 1950s, the concepts employed in programming were being developed alongside machine design. These varied much less than the design of the early machines (ASCC, Bell Labs relay machines, ENIAC, EDVAC, EDSAC, and ACE). Following this period, in the 1950s, programming went through a crucial change from automatic coding to programming languages. Developments in automatic coding intertwined with developments in machine translation and notation. The concept of universal languages also belong to this era, when Fortran and LISP and the first draft of Algol were developed.
Analysis of the Algol research program forms the core of the book. Priestley attempts to answer the question that the Russian computer scientist Andrei Petrovich Ershov posed to Robert Bemer: Why did Algol, despite its seemingly disappointing history, change the face of programming?1 Priestley views Algol 60 as an "obvious landmark"—a term taken from the first ACM History of Programming Language (HOPL) Conference—and as a paradigmatic change in the Kuhnian sense. Priestley skillfully explains how the story of Algol 60 fits the idea of a research program developed by the philosopher of science Imre Lakatos. Beyond the technicalities of the programming language, Priestley notes the invention of institutions as communication vehicles. Such institutions included the committee style of work on Algol 60, which had already been adopted for the Algol 58 report, and the Algol Bulletin, founded and edited by Peter Naur. However, Priestley does not go beyond the technical level in exploring the relationship between the individual actors.
After the publication of the Algol 60 report, new issues arose in programming. For example, computer programmers dreamed of replacing the debugging of a program with a proof that showed the program met particular specifications. They also developed structured programming and, over time, found that their use of programming languages also influenced their treatment of data structures.
Although Priestley's book is mostly based on English-language published and archival material (as an appendix, the complete table for the universal Turing machine is included), it presents a variety of viewpoints. In fact, the effort to embrace the whole story becomes detrimental. For example, in Chapter 3, Priestley juxtaposes Hollerith machines and the work of Leslie J. Comrie as two examples of semiautomatic computation, and in Chapter 4, he deals with what is traditionally taken as the "other" source of the development of modern computers and their programming: logic and formal systems. These two chapters do not even inspire the author to write his own conclusions, which he does in other parts of the book.
In general, Priestley does an excellent job describing the technical work of the individual characters in his book. Beyond the account of technicalities, he draws general conclusions...