mechanical technology to complement the exotic electronic processing going on in the mainframe. It was a utilitarian device but one that users had an irrational affection for. At nearly every university computer center, someone figured out how to program the printer to play the school’s fight song by sending appropriate commands to the printer. The quality of the sound was terrible, but the printer was not asked to play Brahms. Someone else might use it to print a crude image of Snoopy as a series of alphabetic characters. In and out of Hollywood, the chattering chain printer, spinning tapes, and flashing lights became symbols of the computer age. Conclusion By 1960 a pattern of commercial computing had established itself, a pattern that would persist through the next two decades. Customers with the largest needs installed large mainframes in special climate-controlled rooms, presided over by a priesthood of technicians. These mainframes utilized core memories, augmented by sets of disks or drums. Backing that up were banks of magnetic tape drives, as well as a library where reels of magnetic tape were archived. Although disks and drums allowed random access to data, most access conformed to the sequential nature of data storage on tapes and decks of cards. For most users in a university environment, a typical transaction began by submitting a deck of cards to an operator through a window (to preserve the climate control of the computer room). Sometime later the user went to a place where printer output was delivered and retrieved the chunk of fan-fold paper that contained the results of his or her job. The first few pages of the printout were devoted to explaining how long the job took, how much memory it used, which disk or tape drives it accessed, and so on—information useful to the computer center’s operators, and written cryptically enough to intimidate any user not initiated into the priesthood. For commercial and industrial computer centers, this procedure was more routine but essentially the same. The computer center would typically run a set of programs on a regular basis—say, once a week— with new data supplied by keypunch operators. The programs that operated on these data might change slightly from one run to the next, although it was assumed that this was the exception rather than the rule. The printouts were ‘‘burst’’ (torn along their perforations), bound between soft covers, and placed on rolling racks or on shelves. These Computing Comes of Age, 1956–1964 77 printouts supplied the organization with the data it needed to make decisions and to run its day to day operations. Thus the early era of computing was characterized by batch proces- sing. The cost of the hardware made it impractical for users to interact with computers as is done today. Direct interactive access to a computer’s data was not unknown but was confined to applications where cost was not a factor, such as the SAGE air defense system. For business customers, batch processing was not a serious hindrance. Reliance on printed reports that were a few days out of date was not out of line with the speeds of transportation and communication found elsewhere in society. The drawbacks of batch processing, especially how it made writing and debugging programs difficult, were more noticed in the universities, where the discipline of computer programming was being taught. University faculty and students thus recognized a need to bring interactive computing to the mainstream. In the following years that need would be met, although it would be a long and difficult process. Table 2.2 lists the characteristics of some of the machines discussed in this chapter. Table 2.2 Characteristics of selected computers discussed in this chapter Year announced Words of main Device Name or installed Word length memory type SAGE 1955–1958 32 bits 8 K Tubes Philco TRANSAC-2000 1958 ——Transistors RCA 501 1958 12 decimal digits Transistors IBM 1401 1959 variable 4–16 K Transistors (7 bits/char.) IBM 7090 1960 36 bits 32 K Transistors 78 Chapter 2 3 The Early History of Software, 1952–1968 He owned the very best shop in town, and did a fine trade in soft ware, especially when the pack horses came safely in at Christmas-time. —R. D. Blackmore, Lorna Doone 1 There will be no software in this man’s army! —General Dwight D. Eisenhower, ca. 1947 2 In 1993 the National Academy of Engineering awarded its Charles Stark Draper Prize to John Backus, ‘‘for his development of FORTRAN the first general-purpose, high-level computer language.’’ 3 The Academy’s choice was applauded by most computer professionals, most of whom knew well the contribution of Backus and FORTRAN to their profession. FORTRAN, although currently still in use, has long been superseded by a host of other languages, like Cþþ or Visual Basic, as well as by system software such as UNIX and Windows, that reflect the changing hardware environment of personal computers and workstations. In accepting the award, Backus graciously acknowledged that it was a team effort, and he cited several coworkers who had labored long and hard to bring FORTRAN into existence. The Draper Prize was instituted to give engineers the prestige and money that the Nobel Prize gives scientists. Here it was being awarded for developing a piece of software—something that, by definition, has no physical essence, precisely that which is not ‘‘hardware.’’ The prize was being awarded for something that, when the electronic computer was first developed, few thought would be necessary. Not only did it turn out that software like FORTRAN was necessary; by the 1990s its development and marketing overshadowed hardware, which was becoming in some cases a cheap mass-produced commodity. How did the entity now called ‘‘software’’ emerge, and what has been its relationship to the evolution of computer hardware? A simple definition of software is that it is the set of instructions that direct a computer to do a specific task. Every machine has it. Towing a boat through a lock of a nineteenth-century canal required a perform- ing sequence of precise steps, each of which had to be done in the right order and in the right way. For canal boats there were two sets of procedures: one for getting a boat from a lower to a higher level, and one for going the other way. These steps could be formalized and written down, but no canal workers ever called them ‘‘software.’’ That was not because the procedures were simple, but because they were intimately associated with the single purpose of the lock: to get a canal boat from one level stretch to another. A canal lock may have secondary purposes, like providing water for irrigation, but these are not the reasons the lock is designed or installed. A computer, by contrast, does not specify any single problem to be solved. There is no division into primary and secondary functions: a stored-program digital computer is by nature a general-purpose machine, which is why the procedures of users assume greater impor- tance. These procedures should be considered separate from the machine on which they run. The word ‘‘software’’ suggests that there is a single entity, separate from the computer’s hardware, that works with the hardware to solve a problem. In fact, there is no such single entity. A computer system is like an onion, with many distinct layers of software over a hardware core. Even at the center—the level of the central processor—there is no clear distinction: computer chips carrying ‘‘microcode’’ direct other chips to perform the processor’s most basic operations. Engineers call these codes ‘‘firmware,’’ a term that suggests the blurred distinction. If microcode is at one end, at the other one encounters something like an automatic teller machine (ATM), on which a customer presses a sequence of buttons that causes a sophisticated computer network to perform a complex set of operations correctly. The designers of ATMs assume that users know little about computers, but just the same, the customer is programming the bank’s computer. Using an ATM shares many of the attributes of programming in the more general sense. Pressing only one wrong key out of a long sequence, for example, may invalidate the entire transaction, and a poorly designed ATM will confuse even a computer-literate customer (like the home video-cassette recorder, which most owners find impossible to program). 80 Chapter 3 Somewhere between these extremes lies the essence of software. One programmer, Scott Kim, said that ‘‘there is no fundamental difference between programming a computer and using a computer.’’ 4 For him the layers are smooth and continuous, from the microcode embedded in firmware to the menu commands of an ATM, with his own work lying somewhere in the middle. (Kim is a designer of personal computer software.) Others are not so sure. People who develop complex system software often say that their work has little to do with the kind of computer programing taught in schools. What is worse, they feel that the way computer programming is taught, using simple examples, gives students a false sense that the production of software is a lot simpler than it is. 5 They also point out that developing good software is not so much a matter of writing good individual programs as it is of writing a variety of programs that interact well with each other in a complex system. The history of software should not be treated separately from the history of computing, even if such a distinction is of value to computer engineers or scientists (figure 3.1). Several of the examples that follow will show innovations in software that had little or no impact until they could mesh well with corresponding innovations in hardware. 6 Likewise, the often-repeated observation that progress in hardware, measured by metrics like the number of circuits on a silicon chip, far outpaces progress in software is probably false. 7 While it is true that hardware technology must face and overcome limits of a physical, tangible nature, both face and overcome the much more limiting barrier of complexity of design. 8 Beginnings (1944–1951) In order to program the electromechanical Harvard Mark I, users punched a row of holes (up to 24 in a line) on a piece of paper tape for each instruction. 9 In the summer of 1944, when the machine was publicly unveiled, the Navy ordered Grace Murray Hopper to the Computation Lab to assist Howard Aiken with programming it. Hopper had been a professor of mathematics at Vassar College and had taken leave to attend the Navy’s Midshipmen School. According to Hopper, she had just earned her one and one-half stripes when she reported to the lab at Harvard. There, Howard Aiken showed her The Early History of Software, 1952–1968 81 a large object, with three stripes waved his hand and said: ‘‘That’s a comput- ing machine.’’ I said, ‘‘Yes, Sir.’’ What else could I say? He said he would like to have me compute the coefficients of the arc tangent series, for Thursday. Again, what could I say? ‘‘Yes, Sir.’’ I did not know what on earth was happening, but that was my meeting with Howard Hathaway Aiken. 10 Thus began the practice of computer programming in the United States. Hopper wrote out the sequence of codes for that series, and later the codes for more complex mathematical expressions—one of the first was a lens design problem for James Baker (a Harvard Fellow known among insider circles for his design of lenses for the top-secret cameras used by U.S. intelligence agencies). 11 Some sequences that were used again and again were permanently wired into the Mark I’s circuits. But these were few and their use did not appreciably extend its flexibility. Since the Mark I was not a stored- program computer, Hopper had no choice for other sequences than to code the same pattern in successive pieces of tape. 12 It did not take long for her to realize that if a way could be found to reuse the pieces of tape already coded for another problem, a lot of effort would be saved. The Mark I did not allow that to be easily done, but the idea had taken root and later modifications did permit multiple tape loops to be mounted. In the design of a later Harvard calculator (the Mark III), Howard Aiken developed a device that took a programmer’s commands, typed Figure 3.1 Relative costs of software vs. hardware for typical systems, 1965–1985. This famous graph was popularized in the early 1970s by Barry Boehm, then of TRW. The graph has been reprinted in numerous textbooks and articles about software development and has become one of the great myths of software. As with any myth there is much truth in this graph, but more recent studies of software expenditures seem to conclude that over the years the ratio has remained more or less constant. (Source : Adapted from Barry Boehm, ‘‘Software and its Impact,’’ Datamation [May 1973]: 49.) 82 Chapter 3 on a keyboard in the notation of ordinary mathematics, and translated them into the numerical codes that the Mark III could execute (figure 3.2). These codes, recorded on a magnetic tape, were then fed into the Mark III and carried out. Frequently used sequences were stored on a magnetic drum. In Germany, Konrad Zuse had independently proposed a similar idea: he had envisioned a ‘‘Plan Preparation Machine’’ (Planfertigungsgera¨te) that would punch tapes for his Z4 computer, built during World War II. 13 Zuse’s device would not only translate commands but also check the user’s input to ensure that its syntax was correct, that is, that it had the same number of left and right parentheses, that more than one arithmetic operation did not appear between two numbers, and so on. Figure 3.2 A programming machine attached to the Harvard Mark III, ca. 1952. The operator is Professor Ambros P. Speiser, of the Federal Technical Institute of Zurich. Programs would be keyed into this device in a language similar to ordinary algebra, and the machine would translate it into the codes that the Mark III proper could execute. With a stored program computer this additional piece of hardware is unnecessary. (Source : Gesellschaft fu¨ r Mathematik und Datenverarbeitung [GMD], Bonn, Germany.) The Early History of Software, 1952–1968 83 Zuse never completed the Plan Preparation Machine, although he had refined its design (and changed its name to ‘‘Programmator’’)by 1952. Meanwhile, his Z4 computer had been refurbished and installed at the Federal Technical Institute in Zurich. While using it there, Heinz Rutishauser recognized an important fact: that a general-purpose computer could itself be programmed to act like such a ‘‘Programma- tor,’’ getting rid of the need for a separate machine. Solving a problem would thus take two steps: one in which the computer is programmed to check and translate the user’s commands, and another to carry out these commands, which are now encoded in numerical code on a piece of tape. 14 Rutishauser stated it simply: ‘‘Use the computer as its own Plan Preparation Machine.’’ 15 None of the machines described above stored their programs in internal memory, which meant that programming them to translate a user’s commands as Rutishauser envisioned would have been very difficult. The Zuse machine, however, had a flexible and elegant design, which inspired Rutishauser to see clearly how to make computers easier to program. Like Hopper’s realization that the tapes she was preparing could be used more than once, Rutishauser’s realization that the same computer that solved a problem could prepare its own instructions was a critical moment in the birth of software. With a stored-program computer, a sequence of instructions that would be needed more than once could be stored on a tape. When a particular problem required that sequence, the computer could read that tape, store the sequence in memory, and insert the sequence into the proper place(s) in the program. By building up a library of sequences covering the most frequently used operations of a computer, a programmer could write a sophisticated and complex program without constant recourse to the binary codes that directed the machine. Of the early stored-program computers, the EDSAC in Cambridge, England, carried this scheme to the farthest extent, with a library of sequences already written, developed, and tested, and punched onto paper tapes that a user could gather and incorporate into his own program. 16 D. J. Wheeler of the EDSAC team devised a way of storing the (different) addresses of the main program that these sequences would have to jump to and from each time they were executed. This so-called Wheeler Jump was the predecessor of the modern subroutine call. 17 84 Chapter 3 UNIVAC Compilers (1952) If these sequences were punched onto decks of cards, a program could be prepared by selecting the appropriate decks, writing and punching transitional codes onto cards, and grouping the result on a new deck of cards. That led to the term ‘‘to compile’’ for such activity. By the early 1950s, computer users developed programs that allowed the computer to take over these chores, and these programs were called ‘‘compilers.’’ Grace Hopper (1906–1992) played a crucial role in transferring that concept from Howard Aiken’s laboratory at Harvard to the commercial world. Even though she had a desire to remain in uniform and the Navy had offered her continued employment in computing, John Mauchly was able to persuade her to join him and work on programming the UNIVAC as it was being built. 18 (She eventually returned to active duty in the Navy and reached the rank of rear admiral at her retirement.) 19 Hopper defined ‘‘compiler’’ as ‘‘a program-making routine, which produces a specific program for a particular problem.’’ 20 She called the whole activity of using compilers ‘‘Automatic Programming.’’ Beginning in 1952, a compiler named ‘‘A-0’’ was in operation on a UNIVAC; it was followed in 1953 by ‘‘A-1’’ and ‘‘A-2.’’ A version of A-2 was made available to UNIVAC’s customers by the end of that year; according to Hopper they were using it within a few months. 21 The term ‘‘compiler’’ has come into common use today to mean a program that translates instructions written in a language that human beings are comfortable with, into binary codes that a computer can execute. That meaning is not what Hopper had in mind. 22 For her, a compiler handled subroutines stored in libraries. 23 A compiler method, according to Hopper’sdefinition, was a program that copied the subroutine code into the proper place in the main program where a programmer wanted to use it. These subroutines were of limited scope, and typically restricted to computing sines, cosines, logs, and, above all, floating-point arithmetic. Compilers nonetheless were complex pieces of software. To copy a routine that computed, say, the log of a number, required specifying the location of the number it was to calculate the log of, and where to put the results, which would typically be different each time a program used this specific subroutine. 24 The metaphor of ‘‘assembling’’ a program out of building blocks of subroutines, though compelling, was inappropriate, given the difficulty of integrating subrou- tines into a seamless flow of instructions. The goal for proponents of Automatic Programming was to develop for software what Henry Ford The Early History of Software, 1952–1968 85 had developed for automobile production, a system based on inter- changeable parts. But just as Ford’s system worked best when it was set up to produce only one model of car, these early systems were likewise inflexible, they attempted to standardize prematurely and at the wrong level of abstraction. But it was only in making the attempt that they realized that fact. 25 Laning and Zierler (1954) The first programming system to operate in the sense of a modern compiler was developed by J. H. Laning and N. Zierler for the Whirlwind computer at the Massachusetts Institute of Technology in the early 1950s. They described their system, which never had a name, in an elegant and terse manual entitled ‘‘A Program for Translation of Mathematical Equations for Whirlwind I,’’ distributed by MIT to about one-hundred locations in January 1954. 26 It was, in John Backus’s words, ‘‘an elegant concept elegantly realized.’’ Unlike the UNIVAC compilers, this system worked much as modern compilers work; that is, it took as its input commands entered by a user, and generated as output fresh and novel machine code, which not only executed those commands but also kept track of storage locations, handled repetitive loops, and did other housekeeping chores. Laning and Zierler’s ‘‘Algebraic System’’ took commands typed in familiar algebraic form and translated them into machine codes that Whirlwind could execute. 27 (There was still some ambiguity as to the terminology: while Laning and Zierler used the word ‘‘translate’’ in the title of their manual, in the Abstract they call it an ‘‘interpretive program.’’) 28 One should not read too much into this system. It was not a general- purpose programming language but a way of solving algebraic equa- tions. Users of the Whirlwind were not particularly concerned with the business applications that interested UNIVAC customers. Although Backus noted its elegance, he also remarked that it was all but ignored, despite the publicity given Whirlwind at that time. 29 In his opinion, it was ignored because it threatened what he called the ‘‘priesthood’’ of programmers, who took a perverse pride in their ability to work in machine code using techniques and tricks that few others could fathom, an attitude that would persist well into the era of personal computers. Donald Knuth, who surveyed early programming systems in 1980, saw another reason in the allegation that the Laning and Zierler system was slower by a factor of ten than other coding systems for Whirlwind. 30 For 86 Chapter 3 [...]... chapter 7 Sorting Data Regardless of what level of programming language they used, all commercial and many scientific installations had to contend with an activity that was intimately related to the nature of the hardware— The Early History of Software, 1952–1968 89 namely, the handling of data in aggregates called files, which consisted of records stored sequentially on reels of tape Although tape offered... programming always seemed to be in a state of crisis and always seemed to play catch-up to the advances in hardware This crisis came to a head in 1968, just as the integrated circuit and disk storage were making their impact on hardware systems That year, the crisis was explicitly acknowledged in the academic and trade literature and was the subject of a NATO-sponsored conference that called further attention... a characteristic that reflected its creators’ desire to retain the power of assembly language.78 To that extent it went against the tenets of structured programming that were then being espoused That quality also made it one of the most popular languages of the personal computer era, as practiced at the giant software houses of the 1990s such as Microsoft The success of UNIX and C balanced two failed... that ALGOL would become a worldwide standard not tied to IBM, but that did not happen One member of the ALGOL committee ruefully noted that the the name ALGOL, a contraction of Algorithmic Language, was also the name of a star whose English translation was ‘‘the Ghoul.’’ Whatever the reason for its ill fate, ALGOL nonetheless was influential on later languages Of the many other languages developed at... films like Blade Runner or Brazil As far as the eye could see were rows of IBM Model 027 keypunches—machines that punched rectangular holes into 80-column cards, each of them a standard 3- 1/4 6 7 -3/ 8 inches Seated at each station was a woman, her head tilted to the left to scan a piece of paper mounted on a frame, her right hand deftly floating over the keys of the machine Each press of a key caused it... insatiable appetites for computing power The United States was entering a decade of economic growth and prosperity, accompanied by major investments in interstate highways, suburban housing, and jet aircraft All of these put a strain on informationprocessing procedures that were based on punched card tabulators, mechanical adding machines, and calculators Computing in the 1960s was not just a story of. .. department, with major laboratories on both coasts as well as in Europe, to ensure that it could stay abreast of developments in solid-state electronics, tape and disk storage, programming languages, and logic circuits Some of that research was conducted at fundamental levels of solid-state physics and mathematics, which offered little chance From Mainframe to Minicomputer, 1959–1969 111 of a quick payoff, but... language at all, that was a fatal omission.79 In the mid-1960s, the International Federation for Information Processing (IFIP) established a working group to extend the ALGOL language, and they released a new version of it, which came to be known as ALGOL-68.80 It, too, failed in the marketplace, but for different reasons Whereas ALGOL-60 was based on a formal structure and was very lean, ALGOL-68 was burdened... UNIVAC executive, she was summarily thrown out of his of ce Later on she realized that the very notion of a computer was threatening to this executive; to have it ‘‘speaking’’ French a language he did not speak—was too much.49 Languages Versus Software From the twin peaks of FORTRAN and COBOL we can survey the field of software through the 1960s After recognizing the important place of assembly language... Programming Languages The emergence of that term had to do with their sharing of a few restricted attributes with natural language, such as rules of syntax The history of software development has often been synonymous with the history of high-level programming languages— languages that generated machine codes from codes that were much closer to algebra or to the way a typical user might describe a process . drives, as well as a library where reels of magnetic tape were archived. Although disks and drums allowed random access to data, most access conformed to the sequential nature of data storage on tapes. the Navy ordered Grace Murray Hopper to the Computation Lab to assist Howard Aiken with programming it. Hopper had been a professor of mathematics at Vassar College and had taken leave to attend. individual programs as it is of writing a variety of programs that interact well with each other in a complex system. The history of software should not be treated separately from the history of computing,