by Kurt W Beyer
Hopper and crew usually were too busy solving problems for the war effort to speculate about the calculating machine’s commercial potential. This was the case even after the laboratory received several inquiries from interested industry leaders through the summer and fall of 1944. A series of articles was published after the machine’s official dedication on 7 August 1944, and companies such as Eastman Kodak and Goodyear Aircraft Corporation made inquiries about the possibility of running engineering problems. Each inquiry was met with a form letter from Commander Aiken regretting that the laboratory could not accommodate the request because Mark I was engaged in the solution of problems strictly for the war effort. In the final sentence, the letter said “perhaps, at some future date, after the war, we may be of service to you.”51
The only discussion Hopper recalled during the war concerning the commercial potential of Mark I occurred while visiting her parents on Christmas leave in 1944. Hopper’s father was a prominent figure within the insurance industry, with more than 50 years’ experience, and her grandfather had been president of the Great American Insurance Company. When Hopper told her father about her work at Harvard, he immediately understood Mark I’s commercial potential for keeping records, calculating premium tables, and generating premium and billing statements. “Now whether he had gone to New York and mentioned that to any of the insurance companies, I’ll never know, but that was the first mention that I ever heard of using the computer in industry,” Hopper recalled. “It was from my own father.”52
THE POSTWAR ENVIRONMENT
With the conclusion of the war, the Harvard Computation Laboratory’s future was in question. The Bureau of Ships contract was to run out, and Aiken had to find a new patron for his machine. Though the Harvard administration’s attitude toward Aiken and the Computation Laboratory had softened with the success of the project, Aiken felt limited allegiance to those who had not supported him earlier. “We entered into a phase in which ‘Howard Aiken had a computing machine and nobody in the University could get near it’, which, in part, was true,” recalled Aiken. “However, since we had paid for it ourselves or raised the money to pay for it, it did not disturb me very much.”53
Since Aiken was not motivated by financial gain, he did not consider exploring his invention’s business potential.54 Instead, he renegotiated with the Navy and signed a new contract with the Bureau of Ordnance in the fall of 1945. The contract transferred control of Mark I to Ordnance from the Bureau of Ships, which dedicated the machine to engineering and scientific problems pertaining to national security. The contract also extended funding of the proposed Mark II and made provisions for research and development of Mark III.55
In order to preserve the Computation Laboratory’s organizational continuity, the contract recommended that the indispensable members of the crew be removed from active duty and employed as civilians. This included Aiken, Hopper, Campbell, and Bloch in particular. Harvard agreed to assign Aiken and his staff to the newly created Department of Engineering Sciences and Applied Physics, naming Aiken an associate professor and Hopper, Campbell, and Bloch research associates.56
The original members of the crew served as the nucleus for the laboratory’s postwar expansion. To maximize their investment, the Navy still wanted to operate the machine 24 hours a day and seven days a week. But since the staff was now civilian, the Navy had to abide by the peacetime directive of a 40-hour workweek. For this reason, it hired a second shift of operators and programmers. Numbers also increased because of the need to design and build the Mark II and Mark III. Because Aiken would not receive direct assistance from IBM or any other commercial manufacturer, the appropriate number of engineers and technicians had to be hired to meet the terms of the contract.
One of the first hires after the war was Harry Goheen, who had received his doctorate in mathematics from Stanford in 1940 and had enlisted in the Navy after Pearl Harbor because, he recalled, “it seemed that I might possibly be of greater assistance as an active duty officer at sea.” But instead of finding glory and adventure on the bridge of a battleship, Goheen had a “terribly boring experience” as an armed guard in the Philippines.57
Goheen left Manila in July 1945 and arrived at the Computation Laboratory in August. Hired as a coder, on the side he helped Hopper prepare the Manual of Operation. “I never did learn to program, but that was what I was supposed to be doing,” said Goheen. He was immediately struck by the intense, almost repressive nature of the laboratory’s environment. In particular, he saw Aiken and Hopper as zealots who were completely dedicated to this strange new computing discipline. Even though the laboratory was transitioning to a peacetime environment, Goheen noted how martial the atmosphere remained.58
Goheen was very empathetic to those who were not enthusiastic about the laboratory culture. “There were a couple of people who, for one reason or another, had felt very badly put upon. I won’t mention any names, but they left,” he recalled. “And I don’t blame them because from their own point of view they got a very raw deal at Harvard.”59 A confidential memorandum from Lieutenant Commander Edmund Berkeley, dated 27 May 1946 corroborates Goheen’s unsettling assessment. Berkeley, assigned by the U.S. Naval Proving Ground to the Harvard Computation Laboratory to aid with the design and construction of Mark II, reported to his superiors on the deteriorating conditions at Harvard after the end of hostilities. Berkeley placed ultimate responsibility and blame for the high rate of personnel turnover on the project’s director, Howard Aiken.60
In his report, Berkeley systematically detailed the unfavorable conditions at the Computation Laboratory, including the length of the work day and the isolation of the staff from similar projects at MIT and the University of Pennsylvania. He named eleven talented people who had left or been dismissed by Aiken between August 1945 and May 1946, noting that all were “very bitter over the conditions on the project.” The root of the problem, according to Berkeley, was that “in the Computation Laboratory there is no provision for appealing any decision or ruling whatsoever made by the project manager.” He was amazed that no one at Harvard and no one in the Navy seemed to have jurisdiction over the rogue director, so that Aiken was able to rule with near absolute authority. Paradoxically, Berkeley concluded, “It seems definitively undesirable that there should be a change in the project manager. The vigor, energy, directness, and intolerance of obstacles which make the problem of dealing with personnel difficult, are in many respects virtues in the struggle to wrest information out of the scientific unknown.” Such was the contradiction of Howard Hathaway Aiken.61
With so many members of the crew leaving, their replacements had difficulty integrating into the Computation Laboratory’s culture. The members of the original crew had forged a powerful bond during the hardship of the war years, and it became very difficult for new recruits to prove their worthiness. Harry Goheen got along with Grace Hopper, his immediate boss, but he was well aware that they were on two different levels in Aiken’s caste system. “She was on the inside, you see. The difference between Grace and us was that she was the Commander’s right-hand girl,” stated Goheen. “And he was lucky to have her for a right-hand girl, because she was most skillful in writing and she worked hard, and she was a clever mathematician, and completely dedicated both to computing machinery and to Howard Aiken.”62
Hopper’s special relationship with Aiken afforded her freedom of thought and action that others did not possess. Fred Miller remembered that her opinions, both technical and organizational, carried more weight than those of other staff members. She entertained important visitors to the Computation Laboratory in Aiken’s absence, and she was the only one permitted to travel to other computing projects. Hopper, Goheen recalled, “was the only one who had that freedom, not only of movement but of moving at [Aiken’s] level.”63
POSTWAR INNOVATIONS AND THE DEVELOPMENT OF SUBROUTINES
For Harry Goheen and for others who had joined the postwar Computation Laboratory, the laboratory’s cultur
e did not encourage experimentation and innovation. Aiken’s hierarchical system left technical decision making to a chosen few. Campbell, Bloch, and Hopper, as members of the original crew, were given special license to innovate, though not at the expense of their primary duties. Despite the marginalization of the inventive spirit at the Computation Laboratory, Bloch and Hopper consolidated the programming insights gained during the war and developed a sophisticated system of subroutines for Mark I in their spare time.
A subroutine was a segment of code representing algebraic functions that could be recorded into and accessed from the internal memory of a computer. A collection of subroutines was known as a subroutine library. During her keynote address at the first History of Programming Languages Conference in 1978, Captain Grace Hopper held up a piece of paper and claimed that it was a subroutine that she had written back in 1944.64 That audacious claim seems questionable on two accounts. First, subroutines are generally associated with stored-program computer architecture, and the Harvard Mark I did not have such an architecture. Second, the majority of the Hopper’s audience, made up primarily of computer pioneers and historians, believed Maurice Wilkes to have been the originator of subroutines and subroutine libraries.65
Wilkes, a British mathematician who made important contributions to the wartime development of radar, was named the director of the Mathematical Laboratory at Cambridge University in 1945. In May 1946, Wilkes was visited by Leslie Comrie, who handed him an unpublished document, written by John von Neumann, titled “First Draft of a Report on the EDVAC.”66 The paper described the architecture of a modern computer: binary logic gates, stored instructions and data, and the serial execution of instructions.
Wilkes spent the summer of 1946 touring the United States in order to learn more about large-scale calculating machines. He attended the Moore School lectures on large-scale calculating machines at the University of Pennsylvania, where he met John Mauchly and Howard Aiken. Mauchly gave Wilkes a tour of the ENIAC, and Aiken invited the British mathematician to the Harvard Computation Laboratory.67
Inspired by the unique calculating machines he saw in Philadelphia and Boston, Wilkes returned to Cambridge determined to construct a machine of his own. The Mathematical Laboratory sponsored a series of colloquia on Thursday afternoons in which issues concerning the proposed computing machine were discussed, oftentimes over a few beers. The Cambridge colloquia attracted researchers and students alike, and it soon evolved into the team that would try to turn the stored-program machine into reality. On 6 May 1949, the EDSAC read its first program into memory and successfully printed the results.68
That same summer, Wilkes established a committee to design a library of coded subroutines. The idea was to generate code for the most widely used elementary functions and standard operations so that future users would not have to program from scratch. The main force behind the programming effort was a recent Cambridge graduate named David Wheeler. Wheeler’s work, which included developing the protocol for the nesting of multiple subroutines, was published in July 1951 under the names of Wilkes, Wheeler, and Stanley Gill. (Gill was a research student.) One thousand copies were sold within the year, including one bought by the senior mathematician at the Eckert-Mauchly division of Remington Rand: Grace Hopper.69
Hopper recalled being impressed by the work of Wilkes, Wheeler, and Gill,70 but found most of the concepts within the book quite recognizable. Seven years before the book’s publication, Hopper and Bloch had stumbled across the subroutine concept while programming Mark I. During the war, they had developed the habit of saving snippets of code as reference material for future coding. “Gradually we built up quite a lot of these little pieces of code in our notebooks,” Hopper recalled.71 Soon it became apparent that different problems could apply the same segments of code. By reapplying pre-written code to new problems, programming time could be reduced.
By the spring of 1945, it was common practice for Harvard coders to share each other’s notebooks in order to copy segments of code. “We would borrow from each other and copy them,” Hopper said. “When we copied them of course we had to change the address. They all started from zero and we had to add those addresses and then we also had to copy them into another program.”72
To facilitate the transfer of code segments into subsequent programs, Hopper and Bloch developed a system they called “relative coding.” The codes were relative because they were written in a general, abstract fashion that allowed them to be entered anywhere in a given program. “I put the A’s and B’s in instead of the specific storage locations,” Hopper recalled, “and what you had to do if you wanted to use it over again, was you put your argument in A, and so on in B.”73 Hopper’s relative codes provided the framework for a given mathematical function. All the user had to supply was the specific parameters of the operation. For example, if the relative code was a general segment for sine, the coder may specify solutions for a range of angles.
Even though Hopper and Bloch’s system of relative coding made it easier to write more accurate codes in less time, the system itself was haphazard. It was up to the coder to remember the contents of the notebooks. When a useful code segment was located, it was copied by hand into the subsequent program. Furthermore, the data and parameters unique to the problem were hand-punched and manually fed into a set of mechanical inputs called interpolators. Human intervention in the copying process increased the probability of mistakes.
With the conclusion of the war, Hopper and Bloch had more time to systematize the relative coding process. The rigid sequential nature of Mark I design proved to be a considerable hindrance. The main sequence mechanism was unidirectional, meaning that reversing or back-stepping the mechanism was impossible. If a segment of code was to be repeated in a given problem, the entire sequence had to be punched into the tape multiple times, since each line of code could be executed only once. “No matter how clever the coding,” Bloch recalled, “it was not possible (without manual intervention) to arrange for embedded subroutines, or to skip certain lines of code, or to branch to another segment of the program.”74
Branching permits a computer to make a decision based on the result of intermediate output. That is, intermediate output A would initiate coding instruction X, whereas output B would precipitate instruction Y. During the war, branching was achieved by having the enlisted operators monitor intermediate results and manually switch or advance main sequence tapes when desired outputs appeared. “The operator would twirl the drum that held the tape over to an indicated branch line and proceed from there,” Bloch recalled. “You had instructions that would say ‘if the machine stops here, move it over to the red line next. If it stops somewhere else, ship it over to the blue line.’ ”75 This crude and time-consuming procedure was painfully evident when trying to calculate John von Neumann’s implosion problem for the first atomic bomb in the fall of 1944. The complex partial differential equations associated with the implosion problem required hundreds of manual manipulations, much to the dismay of Mark I operators.76
In the summer of 1946, shortly after his decommission from the Navy, Bloch took on the challenge and produced a subsidiary sequence unit that permitted full branching capability. The unit could call in up to ten different sub-sequences of code, each with up to 50 lines of instruction. The sub-sequences of code were in fact the relative codes from the notebooks, pre-punched and devoid of bugs. In essence, Bloch and Hopper had created a fully functioning subroutine system, albeit saved on paper tape instead of stored in the machine’s memory. “This was,” Bloch recalled, “the first instance that I know of subroutines in any computer and branching of that nature, being able to go to any of ten subroutines based upon the results that might occur.”77
Combining the subsidiary sequence unit with relative codes provided Harvard coders with a powerful programming tool. “You avoided errors because you used previously checked out valid pieces of code that you knew worked which meant you could write the program much faster and much e
asier,” Hopper recalled.78 Once a clean code was created, it could be plugged into any number of problems. This eliminated several steps, including translating the mathematical problem into code, punching the code, debugging the code, and testing the code. With blocks of relative codes controlled by the subsidiary sequence unit, new problems no longer had to be solved from scratch.
Hopper’s and Bloch’s coding innovations were captured by Aiken in the design of his third calculating machine, the Harvard Mark III. Mark III was assembled at Harvard on contract for the Dahlgren [Virginia] Naval Proving Ground between 1946 and 1948 and was delivered to Dahlgren in January 1950. The machine was unique in utilizing magnetic tape for the input and output of data, vacuum-tube circuitry for registers, and separate magnetic drums for data and instructions storage.79
The magnetic drums were Aiken’s attempt to solve the problem of effective, high-speed internal memory.80 Each was 8 inches in diameter, 40 inches long, and covered with a thin plastic layer with embedded ferrous oxide. As the drum rotated, the read/write heads magnetized spots that represented data along the drum’s surface, which could be re-read at a later date. In this respect magnetic drums operated in a similar fashion to audiocassette tapes, but the information could be accessed randomly and not just in sequential fashion as with tapes. Hopper recalled the difficulty the crew had finding a manufacturer who could produce a drum that did not bulge in the middle when rotated at high speeds.81 Eventually the horizontally mounted drums achieved an operating speed of 6,900 rpm and could store up to 4,000 instructions, making them the most robust storage medium to date.
The expanded memory permitted programs to be stored internally,82 which allowed instructions to be accessed at the speed of the arithmetic unit. Now all that was necessary was to speed up the coding process itself. Aiken’s solution was to mechanize Hopper and Bloch’s relative code system. A library of prewritten relative codes was housed within a mechanical coding device (later referred to as the Instructional Tape Preparation Table). That device permitted the coder to introduce complete, multi-instruction subroutines at the push of a button. For instance, the “cosine” button placed the proper code sequence onto the magnetic instruction tape, set parameters for the position of the decimal point, and managed address storage information for instructions after completion of the cosine routine.83