Grace Hopper and the Invention of the Information Age

by Kurt W Beyer

  It was at the NRL, in January 1944, that Bloch first met Commander Howard Aiken, whom he had been assigned to escort on a tour of the facilities. “When he heard of my background at Harvard, he asked me would I like to get involved,” Bloch recalled. “He told me about this fabulous machine that he had designed and asked if I would like to spend my Naval duty up at Harvard. Of course it sounded intriguing to me, so I jumped at it.”45 At the time Bloch hadn’t a clue what Aiken was actually talking about, but on a leap of faith the ensign reported for duty in March 1944. When Bloch arrived at Harvard, Mark I had recently arrived from Endicott. What Ensign Bloch saw on his first day at Harvard was much more spectacular than he had expected.46

  So Mark I—the most complex, unique computing machine ever created—was placed in the care of a 37-year-old newly minted naval officer and her 23-year-old sidekick. Howard Aiken and the engineers at IBM had turned a Harvard graduate student’s idea for an automated computing machine into a physical reality. It was now up to Grace Hopper and Richard Bloch to communicate with the hulking machine and make it do their bidding. Little did the two know at the time that their work over the next year not only would strongly assist the war effort but also would demonstrate to America’s military, academic, and business elites the viability of large-scale automated computing machines, otherwise known as computers.

  3 THE ORIGINS OF COMPUTER PROGRAMMING

  How does one go about programming the world’s first operational computer? With mentors of limited knowledge and experience, Lieutenant Hopper was faced with the daunting task of making the Harvard Mark I’s 750,000 parts move with purpose and generate accurate solutions. These solutions, far from academic curiosities, were answers to problems with immediate military applications. In the face of unusual wartime pressures, Hopper relied on her ability to stay calm and rationally think through problems.

  The neophyte coder realized that she needed to understand the hardware of Mark I in all its intricate detail if she hoped to have the machine calculate according to her will. This meant quickly educating herself in electronics, despite her limited engineering background. During her first 2 months at Harvard, Hopper spent nights combing through the machine’s basic blueprints and circuit diagrams. If she could not understand the purpose of a certain switch or relay, she tracked down Bob Hawkins, an electrical and mechanical maintenance engineer who quickly became known to the early Mark I crew as “Mr. Fixit.”

  Hopper’s resolute effort to understand the machine’s hardware provides insight into an aspect of her innovative style.1 The former college professor was not one to back down from an intellectual challenge, even when the subject matter lay outside her realm of expertise. Nine years at Vassar auditing assorted classes and teaching non-math courses had given her confidence that she could learn just about anything. The new knowledge, when mixed with what she already understood, made Hopper a potent problem solver. To be a better programmer, she first needed to comprehend the peculiar physical nature of Aiken’s creation. Hopper’s diligence would pay dividends in avoiding coding pitfalls in the coming months and years.

  Lieutenant (j.g.) Hopper and Seaman White inspecting Mark I’s hardware, 1944. Courtesy of Archives Center, National Museum of American History, Smithsonian Institution.

  During her impromptu education in hardware design, Hopper was astonished by the machine’s sheer complexity and size. Mark I contained more than 3,500 electromechanical relays, 2,300 storage counters, and thousands of back-wired relay terminals. The myriad of parts was orchestrated by a unique 3-inch-wide punch tape that sequentially entered coded instructions into the machine. Unlike IBM calculating machines based on punch-card technology, the continuously fed coded patterns could, in theory, execute a problem from start to finish without the intervention of an operator. The instructions on the punch tape were “fixed” in the sense that there was no way to modify the sequence of instructions that the machine was to obey without direct human intervention. This innovation was captured in Mark I’s official name: Automatic Sequence Controlled Calculator.2

  Each sequence of coding on the punch tape was broken down into three sections of eight round holes no more than 1/16 inch in diameter. The first section instructed the machine where to find its data; the second indicated where to place the results; the third dictated the process to be applied. The holes were punched according to an eight-bit code that spatially correlated to the numbers 1 through 8 (the number 9 represented a “minus” sign). For example, the code “753” was represented by holes in the 7, 5, and 3 places on the tape. Automatic codes directed the machine to perform specific operations, such as punching output into punch cards and printing on a typewriter. Automatic codes were contained in a codebook or were memorized by the crew.

  Though far more complex, Mark I’s coded tapes worked in a similar fashion to a variety of other automated devices that appeared with increased regularity during the nineteenth century and the first half of the twentieth.3 Player pianos, glockenspiels, and semi-automated textile looms all followed the principle of sequenced information embedded in a control mechanism that manipulated the outcome. These machines were hardware specific, however; for example, a player piano could play a fugue or a sonata on the basis of data entered, but it could do no more. What made Mark I unique was that both data and operations could be changed, thus allowing the machine to “simulate” the trajectory of a rocket, the movement of a ship, or even the notes played by a piano. Mark I was the first general computer in the sense that it could become whatever the operator wanted it to become.

  But Mark I’s flexibility was limited by its processing speed. The cycle time for the thousands of parts was determined by a central driveshaft that spun at 200 rpm. The shaft’s rotation translated into a basic computational speed of 300 milliseconds. That is, the main shaft completed a revolution every 3/10 second. The shaft drove the complete skeleton of gears, which manipulated the counter wheels. Therefore, the actual insertion of information, or the addition or subtraction of two digits, was a mechanical process done by the rotation of the counter wheels. Multiplication and division, on the other hand, were computed in a separate multiplication section of the machine.4

  The cycle time of 300 milliseconds corresponded to the execution of one line of coding. This also equaled one addition operation or one subtraction operation. (The laptop computer used to write this book has the capacity to make 1 billion additions per second, and can process information 333 million times as fast as Mark I.) More complex mathematical processes were even slower. A single multiplication could take just under 10 seconds to complete; a single division took nearly 16 seconds. For logarithms, Mark I’s main shaft had to spin 298 times, thus taking 90 seconds for this one operation.5

  By modern computing standards, Mark I’s memory capacity was also severely limited. Mark I had 72 storage registers, each capable of holding a 23-digit decimal number and its algebraic sign. Just as an automobile’s odometer stores mileage information on numbered wheels connected by a system of toothed gears, Mark I used a system of gears, but with ten stable positions to represent numerical information. The storage registers allowed the machine to maintain intermediate results internally and proceed with further calculations. The machine could also call upon other inputs via switches, data tapes, and punch cards. Output was captured on punch cards or with automated typewriters. Ultimately, the entire 81 feet of gears, switches, wheels, rods, shafts, wires, and tapes was attempting to mimic a human “computer” equipped with a pencil and a pad of paper.6

  TAMING THE MECHANICAL BEAST

  After a month or two working with Aiken’s “Automatic Sequence Controlled Calculator,” it was apparent to both Hopper and Bloch that the machine was anything but automatic. Automation of Mark I did not occur without a great deal of planning and coding. Bloch thought the process was analogous to a supervisor “calling off the shots—calling the sequence of operations to take place.”7 For example, in any given run, Hopper had to define output accuracy
to the decimal (e.g., tenth, hundredth, thousandth). This was accomplished by means of an associated plug wire array that had to be re-plugged from problem to problem. In fact, every machine function had an associated plug wire array, and plug instructions had to be specified accurately for every run of the machine. An error in plugging instructions would cause a given run to abort, and, as Hopper discovered through experience, an inadvertent crossing of wires would have disastrous results.8

  In an attempt to reduce the time needed to code the machine, Mark I contained built-in mathematical functions. These included multiplication, division, and three functions that are commonly seen on hand-held calculators today: logarithms, the sine function, and scientific notation (10x). In fact, these functions were responsible for a considerable fraction of the machine’s relays, and Aiken had expended a great deal of energy designing them. For all his efforts, Hopper concluded that it was best to code for these manually. The hard-wired functions required approximately 200 machine cycles, or about a minute, to produce a result accurate to 23 places; manual coding required a fraction of that time. Most of the time saving was attributable to the flexibility of manual coding. If, for a given problem, variable x represented the angle of roll of a ship, common sense dictated that the problem only needed to be solved for a limited range of values. Harvard’s mechanical brain was not savvy enough to differentiate between capsized ships and ones that floated.

  Hopper discovered other odd hardware peculiarities that further limited the machine’s automated nature. A nine in the 24th column of the register represented a negative quantity. Because of the end-around carry circuit, each register enabled a carry from the 24th column to the first column. This meant that whenever a problem resulted in a carry, nines had to be supplied to the left of the most significant digit in the shifted result if the quantity were negative, or else a huge negative number would result. If all nines were in the storage register, a negative zero would result. If all zeros where in the register, a positive zero would result. Keeping track of negative zeros, positive zeros, and nines became a task in and of itself, yet was critical in order to bring a problem to a successful conclusion. In the end, the coding practices developed by Hopper and Bloch during the war would have to be adapted to the machine’s bizarre hardware design.

  Hopper’s immediate interest in the hardware of Mark I highlights the fact that hardware and software were not clearly demarcated at the genesis of modern computing. This blurring of hardware and software was far more apparent in the other major American wartime computer, the ENIAC (Electronic Numerical Integrator and Computer),9 a fully electronic calculating machine developed by John Mauchly and J. Presper Eckert Jr. at the University of Pennsylvania with financial support from the US Army. Instead of electromechanical relays, Eckert and Mauchly employed 18,000 vacuum tubes as computing switches, thus allowing speeds of up to 5,000 computations per minute. Since the electronic speeds were far greater than the speeds at which instructions and data could be fed into the machine via tape, the ENIAC had to be physically reconfigured to represent the problem to be solved. That is, its hardware was re-wired in order to solve ballistics problems for which it was specifically designed. Hence, there was no coding, just hardware manipulation.10

  “The system design of the ENIAC,”Robert Campbell correctly points out, “derived more from analog techniques than it did from anything else. It was sort of a translation into digital terms of the analog type of system design.”11 In other words, the “programming” of the machine was primarily the way one interconnected the physical units of the machine. In this sense the ENIAC was much like Vannevar Bush’s differential analyzer, a sophisticated mechanical computing device that the renowned MIT engineer invented during the 1930s. The design similarity was no accident: the University of Pennsylvania had a differential analyzer, and both Eckert and Mauchly had been trained on it. Hopper’s firsthand experience with the ENIAC in 1945 during a visit to Philadelphia reiterates this point:

  When I visited ENIAC, the tremendous contrast between Harvard and the activities of Eckert and Mauchly was the programming. You see ENIAC was—you plugged the pieces and essentially you built a special computer for each job, and we were used to the concept of programming and controlling it by our program; there was a very sharp contrast between the automatically sequenced and the plugboard system of ENIAC.12

  To assist in the time-consuming task of reconfiguring ENIAC hardware for each problem, Eckert and Mauchly hired six women from the U.S. Army’s Ballistic Research Laboratory. The BRL employed about 200 “computers,” the majority of them recent female college graduates from the Philadelphia and Baltimore area, to calculate firing tables for artillery. Much like Campbell, Hopper, and Bloch at Harvard, the women of ENIAC soon realized that the only way to accurately program the machine was to be intensely familiar with its hardware and circuit design. The pioneers of software, were, essentially, hardware experts.

  THE WORLD’S FIRST DATA-PROCESSING CENTER

  Six days after Lieutenant (j.g.) Grace Hopper was introduced to the Harvard Mark I, Allied troops stormed the beaches of Normandy. This daring landing, involving more than 5,000 ships, 11,000 planes, and 160,000 troops, attacked a 50-mile stretch of heavily defended French coastline. History has certified the D-Day invasion as the beginning of the end of Hitler’s grip on the European continent, but for Hopper and the staff at the Computation Laboratory the outcome of Operation Overlord was still in the balance through the early summer of 1944. Moreover, the outcome in the Pacific was undetermined, as the Japanese continued their offensive through the spring of 1944 in China and New Guinea.

  World War II created a surplus of practical computational problems that required rapid and accurate solution. Hopper remembered the difficulty of meeting computational demand with the limited laboratory staff, and the anxiety it created for the small team of programmers: “On the Mark I there was Dick Bloch and Bob Campbell and myself. We later acquired two more lieutenant commanders who worked on it. But by and large the three of us did the bulk of the programming.”13 In fact, by the winter of 1944 coding responsibilities almost exclusively fell upon the shoulders of Hopper and Bloch. Campbell spent the majority of his time developing the blueprints for a new computation machine, Mark II. In a desperate attempt to address the ever-growing demand, Hopper and Bloch developed a systematic approach to coding and batch processing that was efficient, accurate, and relevant for future generations of programmers. The wartime demands on the Harvard Computation Laboratory had inadvertently become the engine for programming innovation.

  In typical fashion, Hopper later downplayed the complexities associated with mastering the machine: “You simply step by step told the computer exactly what to do. Now get this number and add it to that number and put the answer there. Now pick up this number and multiply it by that number and put it there. You simply broke down all of your processes of mathematics into a series of very small steps of add, multiply, divide, and make a test, and put them in sequence.”14 Theoretically the concept was not difficult to grasp, but the realities of coding were much more complicated, and the organizational demands substantial. The time sensitivity of the wartime problems only added to the inherent pressures associated with creating technical innovation.

  Commander Aiken, Lieutenant (j.g.) Hopper, and Ensign Campbell standing before Mark I, 4 August 1944. Hopper is holding a sequence-control tape. Courtesy of Harvard University Archives.

  INVENTING A SYSTEM OF CODING

  DEFINING THE PROBLEM

  Hopper and Bloch often found that the problem’s originator could describe the desired results but was at a loss concerning the particular equations that needed to be solved. Conversely, Bloch and Hopper knew little about the context from which problems came. “We had to learn their vocabularies in order to be able to run their problems,” Hopper recalled. “I learned languages of oceanography, of this whole business of mines-weeping, of detonators, of proximity fuses, of biomedical stuff. We had to talk to the
se people—all we had to begin with was mathematics.”15

  Indeed, Hopper’s mathematical background prepared her to break down verbal problems into elementary mathematical parts. She could even handle the complicated partial differential equations associated with heat and fluid flow problems, thanks to her training under the mathematician Richard Courant.16 If she got stuck, Aiken would often help to define a method of solution. “Aiken,” the programmer Harry Goheen recalled, “was a genius at figuring out dirty methods.”17

  Hopper and Bloch soon realized that pre-determining parameters for solution accuracy saved coding time and made results more relevant. “On the first early problems, when we were computing how much accuracy we were having, it was an appallingly rough computation,” Hopper recalled. “We didn’t know much about it yet.”18 Mark I was accurate to 23 decimal places.19 This was necessary when partial differential equations were involved. But more often then not, such extreme accuracy was superfluous. For instance, most ballistic problems required solutions to no more than four decimal places.

  Hopper and Bloch also had to consider the effects of roundoff errors. Luckily, Hopper’s diverse educational background and her 8 years as a professor had prepared her to deal with a wide range of intellectual challenges. “I was unusual because most mathematicians didn’t know anything about round-off errors and truncation errors and the reason I did was because I had taken a course on chemistry,” she recalled. “That is where I had learned about round-off errors and computational errors, not in mathematics.”20

  CONSTRUCTING A CODING BLUEPRINT

  Once the equations were identified, the blueprint of the finalized code had to be planned. This included the mapping of instruction and data tapes and the positioning of decimal places. As previously mentioned, decimal places were controlled by precise plugboard configurations. The limits of storage, physically embodied by the 72 23-decimal registers, severely affected the planning of instruction and data tapes. The result was the necessary segmentation of problems. Intermediate results had to be captured on punch cards and then reentered into the machine as input for the next sequence. Each series of inputs and outputs required the orchestration of multiple instruction tapes and continuous human intervention.