Lesson 1. The developer’s productivity is best served by a tool set whose behavior throughout the development cycle is strictly consistent with the principle that the program being executed is available without delay after every change and is identical to the source program entered by the developer. (That is, there should be no hint of the existence of a translator.)

Stage 1: Quick-turnaround programming tools

The first focus was research in getting the tools out of the way by developing quick-turnaround compilers. The effort produced a few results of note.

1. 1.In 1963 I published two papers [1,2] describing in some detail the design for a one-pass COBOL compiler. I am aware of two commercial compilers based on these ideas. One, for the Burroughs B200/B300 (written under contract by Enn Saumets1) may have set a record for the tiniest machine hosting a real COBOL.
   

2. 2.Under contract to Rockwell Semiconductor I built an immediate-turnaround Pascal trainer for the Rockwell AIM-65, a single-board computer for the 6502 processor (the processor used in the Apple II). This featured single-stepping and debugging at the source level and elimination of any source-target distinction. There is a vintage-computer forum for this product [3] in which people help each other keep this antique running.
   

3. 3.This work led to an arrangement between Apple and Think Technologies (of which I was a principal) under which we produced the original (1984) Mac Pascal [4] and Apple II Instant Pascal [5]. We also built Think Pascal for the Macintosh [6]. All these products had the original instant-turnaround behavior and gave no hint of any internal execution language.

Stage 2: Application language research

My work with computers began in 1956, when the dominant technology for high-volume commercial record keeping was based on drawers full of punched cards. “Programming” file-processing applications (such as utility billing) consisted largely of wiring plugboards and scheduling runs of the files through a few different types of punched-card machines. My exposure to this dying technology was invaluable, as it showed me a largely non-algorithmic application model. The algorithms were incorporated into the machines. Plugboard wiring consisted largely of mapping data between fields on the cards and the final reports (e.g., utility bills). 

Lesson 2. Application languages and algorithm languages are different creatures. The job of a productive application language is not to describe algorithms, but to hide them.

Lesson 2a: The Static Factoring Hypothesis

I came upon this by studying the logic of the IBM 407 punched-card tabulator [7,8] and the first generation of IBM’s RPG (report program generator) language, which was created to wean people used to plugboard wiring over to stored-program computers. The hypothesis applies to serial file processing applications, but it raises the conjecture that it also applies to a very different class of applications: event-driven GUI (graphical user interface) applications. (Later work, see below, confirms the conjecture.)

Applications can be partitioned into classes whereby for each class there is an algorithmic part common to all applications in the class and, for each application in the class, the remainder of the application is an almost totally static parameterization of the algorithmic part. For each class there is at least one corresponding application language that describes the static part and for which the algorithmic part is implied. (In realizations of such languages the algorithmic part appears as a common runtime library.)

The hypothesis would be trivial if each class contained only a single application, but it is not trivial. All punched-card applications constitute one class, and the applications generated by any given serial-file report generator form another class. A punched-card application is described in a flow chart that specifies a network of card-file passes through machines, and each pass is further specified by a wiring panel that is installed in the machine during that pass (or, in the case of the card sorter, a sequence of card columns containing a sort key--the algorithm is burned into the operator’s brain at training time).

End Notes

1. 1.I would like to reconnect with Enn; if anyone knows of his whereabouts please let me know.

CITATIONS

1. 1.Conway, M. E. and Speroni, J.  Arithmetizing Declarations: An Application to COBOL. Comm. ACM  6 (Jan. 1963), 24
   

2. 2.Conway, M. E.  Design of a Separable Transition-Diagram Compiler. Comm. ACM 6 (July 1963), 396
   

3. 3.http://www.vintage-computer.com/vcforum/showthread.php?22210-aim65-pascal-roms
   

4. 4.http://www.danielsays.com/ss-gallery-macintosh-mac-pascal-10.html
   

5. 5.http://apple2history.org/history/ah17/
   

6. 6.http://stackoverflow.com/questions/842866/what-is-it-about-the-think-pascal-debugger-that-makes-it-so-legendary
   

7. 7.http://www.columbia.edu/cu/computinghistory/407.html
   

8. 8.http://www-03.ibm.com/ibm/history/exhibits/vintage/vintage_4506VV4007.html
   

Stage 3: Humanizing application development

As an early placeholder for this discussion you can read this presentation.

To be continued...