by Kurt W Beyer
Tensions between Remington Rand’s sales force and the EMCC staff continued to mount as Hopper and other EMCC programmers found themselves filling the sales, marketing and customer service void left by a sales department with neither the knowledge nor the motivation to sell the expensive, unproven machines. When Rand salesmen did attempt to represent UNIVAC, their incompetence did more harm than good, prompting Herbert Mitchell, Hopper’s former student at the Harvard Computation Laboratory and a senior programmer at EMCC, to send a venomous open letter to senior management:
November 16, 1950
Dear Sales Division,
Please allow me to congratulate you upon your vast knowledge of psychology. You were faced with the task of convincing the EMCC technical people that they should be the ones to popularize the UNIVAC System. However, knowing that they were loath to do a “selling” job, you conceived the brilliant approach of preparing a presentation for customers that was so fantastic, bizarre, and childish that the EMCC would be shocked into the position of demanding to undertake this responsibility. . . . You have succeeded admirable.
We at EMCC are frantic. Faced with the alternative of being made the laughing stock of the entire professional computer field, of losing all possibility of selling any of the computing systems, and hence of being put out of business, we are eager-no, demanding to be given this job. We are convinced and ready.
Very truly yours,
Herbert F. Mitchell Jr.8
In response to the new initiative, members of Hopper’s staff were distributed among regional sales offices in order to answer customers’ questions concerning UNIVAC. Jean Bartik, an original ENIAC programmer, was sent to the Washington sales office in 1950 as the UNIVAC representative. “They didn’t know what to do with me,” she recalled. “Generally, the attitude in the Washington sales force was that Eckert and Mauchly were a bunch of dreamers and didn’t know what they were talking about.”9 Eventually the Rand salesmen got the idea to employ Bartik and her fantastic machine as a ploy to gain entrée into government agencies in hopes of selling other office equipment. “I used to got out and describe UNIVAC and then they would hustle me out of the room, and then the salesmen would sell them typewriters.”10
Another Hopper programmer, Adele Mildred Koss, was assigned to Commonwealth Edison when the utility approached the Chicago sales office concerning a potential purchase of a UNIVAC for billing and payroll. At the time, Koss was 7 months pregnant and working part time. Since her pregnancy precluded travel, Commonwealth Edison management was forced to come to Philadelphia in order to discuss their billing needs. In the end, the utility did not buy a UNIVAC, but instead purchased an IBM 701 when it became available. Koss recalled: “I remember Grace Hopper’s memo to management saying ‘This is a multi-million-dollar client and you are not treating them like one. You have only assigned a part time programmer to work with.’ ”11
The Commonwealth Edison fiasco was not the only matter that made Hopper’s blood boil over the lack of support from Remington Rand management. Beginning with the delivery of the first operational UNIVAC to the Census Bureau on 30 March 1951, the Eckert-Mauchly division was now faced with the task of customer support. According to Hopper, “nobody had realized what it was going to take to support the new user.”12
Eckert-Mauchly’s programmers scrambled to help the new customers in any way they could. Besides developing subroutine packages, Hopper and others visited installations in order to assess computational needs and plan application programs. Much of their effort was spent educating the personnel assigned to operate UNIVAC. Hopper once again relied on her teaching experience, developing curriculum and writing lectures in order to get UNIVAC customers up to speed. Her operational experience at Harvard also served her well as she attempted to set standards and operating procedures both for Eckert-Mauchly and for customers’ installations. “We had to introduce some kind of system and discipline to it,” Hopper recalled, “and that’s how I eventually got put in charge of them. I realized the things that had to be done and I pounded on management until they too accepted the concepts.”13 As the demand for programming and application software increased with each installed UNIVAC, so too did the pressures on Hopper and her programming staff .
THE EDUCATION OF A COMPUTER
For Hopper, the two years that followed the merger with Remington Rand were some of the most trying of her career. The senior programmer’s abilities were stretched to the limit, not to mention the added pressures associated with her managerial duties in the maturing company. But out of crisis flowed resourcefulness, and starting in the fall of 1951 Hopper spent what little spare time she had searching for a technical solution for her predicament.
The mathematician-turned-inventor documented her seven-month creative journey in a paper aptly titled “The Education of a Computer,” which she presented on 3 May 1952 at the Pittsburgh meeting of the Association of Computing Machinery.14 Though Hopper had been sharing her thoughts and ideas with John Mauchly, Betty Holberton, and other close colleagues, it was at the ACM meeting that “automatic programming” was introduced to the greater computing community. Hopper claimed that many in the audience that day were skeptical of her automated coding aspirations. She also noted that about 100 copies of the paper that she had brought from Philadelphia were distributed, which suggests that even those who were skeptical about automatic programming had an interest in finding easier ways to program computers.15 The paper itself represents Hopper’s views circa May 1952, which differ in some respects from her recollections in later interviews and speeches. First and foremost, the central motivations for automatic programming were far more personal in the 1952 paper. With the construction of a functioning compiler, Hopper hoped, “the programmer may return to being a mathematician.” Though Hopper had sincerely enjoyed the challenge of coding since first being introduced to computers 8 years earlier, she wrote, “the novelty of inventing programs wears off and degenerates into the dull labor of writing and checking programs. The duty now looms as an imposition on the human brain.”16 By teaching computers to program themselves, Hopper would be free to explore other intellectual pursuits.
In accord with the first chapter in the Mark I Manual for Operation, the paper begins with a historical narrative identifying the significant figures in computing history. Pascal, Leibniz, Babbage, Aiken, Mauchly, and Wilkes get special mention, while von Neumann, Eckert, Holberton, and Goldstine are notably absent. Hopper writes that her time with Aiken was instrumental in developing the earliest form of subroutines, and that the unique coding machine developed for Mark III represented a hardware solution to the concept of a library of subroutines that could be called upon by means of a mechanical button. Once again she mentions Mauchly’s influence concerning symbolic programming solutions represented by short-order code, and she praises Wilkes for his book, which gave the programming community a shared vocabulary for the concepts of subroutines and subroutine libraries.17 These computing pioneers, according to Hopper, created machines and methods that removed the arithmetical chore from the mathematician. This chore, however, was replaced by the new burden of writing code, thus turning mathematicians into programmers. Hopper’s paper boldly offers the next step in the history of computing: shifting the human-machine interface once again so as to free the mathematician from this new burden, and making “the compiling routine be the programmer and perform all those services necessary to the production of a finished program.”18
Hopper utilizes the metaphor of a factory to make abstract programming concepts more concrete for her audience. On a production line, inputs were raw materials that were acted upon by an assortment of instruments and tools. Human beings dictated the controls that organized the process, and the operation produced output ranging from automobiles to cans of tomatoes. Solving mathematical problems, according to Hopper, was no different. Inputs were alphanumerical data and tools consisted of formulas, tables, pencil, paper, and the arithmetic processing power of the brain. The contr
ols of the process were provided by the mathematician, and the output was the final result.19
The achievement of Aiken, Mauchly, and Wilkes replaced pencil, paper, and the brain with mechanical hardware. But the human was still left to analyze and break down a mathematical problem into its constituent parts, provide step-by-step controls for the process via a program, write that program in notation best understood by the machine, and coordinate the introduction of input. The user was also faced with the significant problem of identifying and correcting for errors. The more complicated the problem, the greater the chance of error.
With the use of a compiler supported by a library of subroutines, Hopper offered to fully automate the computing process:
He [the mathematician] is supplied with a catalogue of subroutines. No longer does he need to have available formulas or tables of elementary functions. He does not even need to know the particular instruction code used by the computer. He needs only to be able to use the catalogue to supply information to the computer about his problem.20
The “catalogue of subroutines” was a menu that listed all the input information needed by the compiler to look up subroutines in the library, assemble them in the proper order, manage address assignments, allocate memory, transcribe code, and create a final program in the computer’s specific machine code.21 A subroutine entry in the catalogue consisted of a subroutine “call-number” and the order in which arguments, controls, and results were to be stated. The call-number identified the type of subroutine (t for trigonometric, x for exponential, etc.), specified transfer of control (entrance and exit points in each subroutine), and set operating and memory requirements. In fact, language such as “call-number” and “library” compelled Hopper to name her program generator a “compiler,” for it compiled subroutines into a program in much the same way that historians compile books into an organized bibliography.22
For Hopper, the benefits of such an automated programming system were enormous. She describes a future in which programs could be written and debugged in hours instead of weeks. The generated results would be accurate, since all subroutines in the library would have been fully debugged and tested. The greatest benefit, however, excited the imagination of the most ardent skeptic. A program generated by a compiler could not only be run as a stand alone program whenever desired; it also “may itself be placed in the library as a more advanced subroutine.” This suggested that subroutine libraries could increase in size and complexity at an exponential rate, thus enabling mathematicians to solve problems once deemed impossible or impractical.23
Hopper ends the paper by establishing a short-term roadmap for the future development of compilers. She describes a “type-B” compiler, which, by means of multiple passes, could supplement computer information provided by the programmer with self-generated information. Such a compiler, she imagines, would be able to automate the process of solving complex differential equations. To obtain a program to compute f(x) and its first n derivatives, only f(x) and the value of n would have to be given. The formulas for the derivatives of f(x) would be derived by repeated application of the type-B compiler.24
Hopper also admits that the current version of her compiler did not have the ability to produce efficient code. For example, if both sine and cosine were called for in a routine, a smart programmer would figure out how to have the program compute them simultaneously. Hopper’s compiler would embed both a sine subroutine and a cosine subroutine in sequence, thus wasting valuable memory and processing time. Hopper states boldly that the skills of an experienced programmer could eventually be distilled and made available to the compiler. She concludes as follows:
With some specialized knowledge of more advanced topics, UNIVAC at present has a well-grounded mathematical education fully equivalent to that of a college sophomore, and it does not forget and does not make mistakes. It is hoped that its undergraduate course will be completed shortly and it will be accepted as a candidate for a graduate degree.25
DISTRIBUTED INVENTION: COMPILER RESEARCH EXPANDS
After publicly announcing the compiler concept, Hopper asked members of her programming staff to help turn her invention into something more substantial. Since there was no formal support from Remington Rand management at this time, those from Rand’s Computation Analysis Laboratory who joined Hopper did so on their spare time.
In the summer of 1952, Hopper’s assembled team began to test the programming aptitude of the compiler (aptly named A-0) against teams of seasoned programmers. Richard Ridgway, a Hopper programmer who joined Eckert-Mauchly in 1950, reported the results of one of these studies on 8 September 1952 at a meeting of the Association of Computing Machinery in Toronto. The equation tested was y = e−x sin(x/2). Given a set of input parameters for x, the Computation Analysis Laboratory first solved for y using what Ridgway referred to as the “conventional” method, which was similar to the batch process method developed by Hopper and Bloch at Harvard. First, a mathematician analyzed the equation and broke it down into a series of arithmetic steps (20 minutes). A programmer then reduced the steps to computer instruction code, utilizing a code manual, tables, and formulas in the process (480 minutes). The completed program was checked for errors (240 minutes), transcribed onto magnetic tape (45 minutes), and rechecked for errors (40 minutes) after printing out the tape’s content (20 minutes). Finally, an operator, following operation instructions, fed the program into computer memory along with pertinent inputs (31 minutes). UNIVAC then ran the program and produced results (4 minutes). In the end, Ridgway reported, the problem was solved from start to finish by a team of three people in 860 minutes.26
The same problem was then solved with Hopper’s A-0 compiler. Once again a mathematician analyzed the problem and broke it down into arithmetic steps. This time, however, the mathematician selected corresponding subroutines from the subroutine library and wrote down the appropriate information to describe these subroutines with the aid of the subroutine library catalogue (20 minutes). The resultant information sheet was transcribed on tape (10 minutes) and proofread (5 minutes) after generating a printout of the tape’s content (5 minutes). The tape was then fed into the computer (2 minutes), which prompted the compiler to look up the appropriate subroutines from the library tape, assemble them in the proper order, manage addresses and memory, and generate a program in C-10 UNIVAC machine code (90 seconds). UNIVAC ran the compiler-generated program and produced the final results (5 minutes). In the case of the A-0 compiler, one person, a mathematician, solved the problem in 48½ minutes.27 (See table 8.1.)
Although the test results appear to be a smashing endorsement of the A-0 compiler, Ridgway dedicates a substantial amount of his paper to the inefficiency of run-programs. (A “run-program” was the final product of the compiler process. Today, such a program is called object or machine code.) During the 5 months since Hopper had introduced compilers, critics had pointed out that run-programs generated by compilers were less efficient than those created by seasoned programmers. Hopper’s experience with Richard Bloch at Harvard was evidence that a creative programmer could use a variety of tricks and tactics to generate code that was 30–40 percent more efficient than that produced by the A-0.
TABLE 8.1
Time preparation comparison: A-0 compiler vs. conventional programming.
Conventional programming Compiler programming Efficiency ratio
Mathematician/programmer’s time 740 minutes 20 minutes 37 : 1
Mathematician/operator’s time 105 minutes 20 minutes 5.3 : 1
UNIVAC processing time 35 minutes 8.5 minutes 4.1 : 1
Total preparation time 880 minutes 48.5 minutes 18.2 : 1
At first glance, program inefficiency did not appear to be significant in Ridgway’s example, for the more inefficient compiled program ran for 5 minutes whereas the programmer-generated code took only 4 minutes. But, programmers argued, that extra minute was relevant if the same program had to be run multiple times. In fact, the vast majority of problems
solved by data-processing facilities in the early 1950s were repeated computations. If Ridgway’s compiled program were to be run 1,000 times, 1,000 extra minutes of computer time would be required.28 The extra computer time generated by the 1,000 runs made the conventional method more time-efficient overall. Furthermore, an hour of computer time was far more costly in 1952 than an hour of programmer time. In most cases it was both more efficient and more cost-effective to hire a team of programmers and operators in order to limit computer use. (See table 8.2.)
TABLE 8.2
A-0 compiler vs. conventional programming method: 1,000 program runs.
Conventional programming Compiler programming Efficiency ratio
Mathematician/programmer’s time 740 minutes 20 minutes 37 : 1
Mathematician/operator’s time 105 minutes 20 minutes 5.3 : 1
UNIVAC processing time 4,000 minutes 5,000 minutes 4 : 5
Total preparation time 4,845 minutes 5,040 minutes 1 : 1.1
Ridgway acknowledged that using compilers took up more computer time, both as a result of compiling a program and as a consequence of inefficient code. But “in this case,” he argued, “the compiler used was the ‘antique,’ or A-0, the first to be constructed and the most inefficient.” Ridgway was confident that Hopper and her team at the Computation Analysis Laboratory would construct new compilers that “squeezed” coding into “neat, efficient, and compact little packages of potential computation.”29