by Kurt W Beyer
Every mature profession, such as medicine or law, has a shared language that members have internalized. A common language serves a variety of purposes. On the most basic level, it identifies and defines important terms and concepts within the community of practitioners. These terms and concepts locate the broad intellectual boundaries of the profession and magnify the subtle details within the landscape. For instance, during her time as the head of the ACM’s Nomenclature Committee, Hopper attempted to move the community away from “words of the magic brain class.” While she was working at Harvard in the 1940s, influential academics such as Norbert Wiener and John von Neumann tended to describe computers as “giant brains” and applied descriptive language that perpetuated this metaphor. Hopper purged these words from computing in the 1950s, replacing “memory” with “storage” and “thinking” with “processing.”1
On a deeper level, a common language helps forge a sense of identity among members of the profession. It facilitates coordination of effort, defines roles, and sustains a feeling of cultural kinship. Hopper found herself at that rare moment during the early years of a budding community when language had not yet precipitated into a more solid, stable state. Fittingly, the person most skilled at communicating with computers was also the central figure in the effort to facilitate communication between people within the maturing profession.
Any discussion of identity brings up questions of power, and Hopper seemed to have been completely aware of that connection. Feminists have long recognized that male-oriented, male-defined language has contributed on some level to the subjugation of women. Hopper was less concerned with gender dominance than with other types of bias built into the language. She readily admitted that the 1954 glossary was UNIVAC oriented and feared that others would reject it out of hand. With that in mind, Hopper opened the language to scrutiny. “It is our earnest plea,” she wrote to fellow members of the Association for Computing Machinery, “that we receive comments, both mild and violent, suggestions, and criticisms as soon as possible.” By broadening participation during the development phase, Hopper increased the odds that the computing community would freely adopt the resultant language.
INVENTION BY COMMITTEE
By 1959, Hopper had proved herself as a businesswoman, a programmer, a naval officer, and an academic. Her multifaceted career, combined with an inventive style that encouraged broad participation, made her the ideal person to orchestrate the creation of a universal, standardized general business language. Hopper’s vigorous efforts to further the cause of automatic programming led to the development of COBOL (Common Business Oriented Language). Although some widely distributed publications (including the New York Times and the Washington Post2) have listed Hopper as COBOL’s inventor, the development of the popular business language is a far more complex story, involving a number of individuals and organizations.
Besides Hopper, the person most cited as the creator of COBOL is Charles Phillips, Director of Data Systems Research at the Department of Defense between 1958 and 1962.3 Yet in a paper presented at the annual conference of the ACM on 1 September 1959, Phillips himself admitted that the idea for COBOL did not originate with him. “We were embarrassed,” Phillips said, “that the idea for such a common language has not had its origin by that time in Defense since we would benefit so greatly from the success of such a project.”4 Phillips credited Grace Hopper and her “idea team” for coordinating the COBOL effort. Hopper, an adjunct professor at the University of Pennsylvania in the spring of 1959, organized a meeting of users, manufacturers, and teachers at the university’s Computer Center on 8 April 1959 to discuss the feasibility of co-developing a common business language.5
Phillips’s account coincides with Hopper’s own recollection of the event.6 According to Hopper, she, Robert Bemer of IBM, and Howard Bromberg of the Radio Corporation of America had been discussing the possibility of creating a common business language for industry. At the time, Bemer was an assistant manager for programming research at IBM and Bromberg was the head of automatic programming at RCA. Before joining RCA, Bromberg had worked under Hopper as a programmer at UNIVAC. “We all knew each other,” Hopper recalled, “but we couldn’t work together and agree on anything because we were breaking antitrust laws. The only way we could all work together and not throw our companies into fits was under the jurisdiction of a university or the government.”7
In order to create a legal forum, Hopper, Bemer, and Bromberg asked Dr. Saul Gorn, Director of Computing at the Moore School of Engineering, to call a meeting to discuss the issue. Gorn, who had been attempting to write a universal computer language himself , invited representatives from industry, government, and academia to the Penn campus. Industry attendees included representative of the main computer manufacturers, as well as the primary users of computers. “We all were in agreement that we would like to have one language for data processing,” said Hopper.8
The chief concern that motivated both manufacturers and users was the rising cost associated with programming. The expenditure for defining business applications, writing, debugging, documenting, and maintaining code, and transferring the program to a second computer accounted for an ever-increasing percentage of total computer outlays. This growing consensus was confirmed by a 1959 survey of prominent user organizations, which concluded that the average programming cost for any large data-processing installation exceeded $800,000. If programs had to be translated in order to run on upgraded hardware, an additional investment of $600,000 was needed. The study also estimated that if the original programs had been constructed in a machine-independent common business language, a full translation could be completed in 6 months (versus 2 years) at a cost of $50,000.9
The daunting question Hopper and the other attendees faced at the 8 April meeting was how to go about crafting a common business language. The group was well aware of the recent development of separate but similar automatic programming languages (among them FLOW-MATIC, COMTRAN, and AIMACO), and that the number of languages would continue to increase if left to the whims of market forces. To avoid the seemingly inevitable “Tower of Babel,” Hopper insisted that users and manufacturers should put aside their private agendas in the name of collaboration. But developing a common, problem-oriented, hardware-independent business language could take more than 10 years, and asking a wide array of organizations to coordinate their efforts for such a long period seemed naive at best.10
After the 8 April meeting, Hopper and the “idea group” searched for an appropriate sponsor for such a formidable undertaking. In order to ensure wide-ranging support from both users and manufacturers, an appropriate sponsor would have to be neutral and would have to possess enough stature to encourage participation. Hopper first solicited the advice of her long-time friend Eugene Smith, a civilian employee of the Navy who had been the Bureau of Ships’ liaison to the Harvard Computation Laboratory during World War II. Smith advised that the Navy was unable to support such an ambitious endeavor, and eventually the group turned to the Department of Defense.
Charles Phillips, who at the time was the DOD’s director of data systems research, recalled being approached by the delegation and being impressed by the “dedicated naval reserve officer who thoroughly understood the DOD problems.”11 As of 1959, the DOD operated 225 internally programmed computers and had ordered 175 more. More than $200 million, according to Phillips, had been spent on application design, flow charting, programming, and debugging. Any means of speeding up software development and reducing operation costs would be welcomed.12
Because the DOD operated a variety of computers from different manufacturers, Phillips was also interested in the possibility of program portability. In 1959, a program written for an IBM machine could not work on a UNIVAC. Hence, each change in hardware necessitated the rewriting of program libraries. Program portability would permit programs to run on different computers, regardless of differences in hardware.
Program portability was well suited to the DOD’
s plan to streamline and consolidate its archaic supply system. For example, in 1959 the military was attempting to reduce costs by unifying its medical supply system across service branches. The Navy had overall management responsibility and coordinated ten major supply depots: four for the Army, five for the Navy and the Marine Corps, and one for the Air Force. Five of the ten depots used five different computers from two different manufacturers; the other five were awaiting computer delivery to replace aging punch-card machines. Since all ten depots used the same stock-distribution system, the savings gained from using one computer program for all ten would be considerable.13
Program portability also could generate other savings for the Department of Defense. According to Hopper, the military’s unique personnel policies added to the costs of programming. Personnel, be they Navy pilots or Air Force computer programmers, served two-to three-year tours of duty. When a tour was completed, the person was sent to a new duty station. Owing to the proliferation of various makes and models of computer hardware, the military spent a considerable amount of money and time retraining personnel. One solution would have been to standardize hardware purchases, but this was impractical because of the dynamic state of the industry. Grace Hopper and the “idea team” convinced Charles Phillips that the best solution would be a portable, common business language that a DOD programmer could learn once. Phillips agreed to put the weight of the military behind the project.14
Phillips tasked Hopper and her colleagues with drafting the agenda for a DOD-sponsored meeting to discuss the feasibility for such an unprecedented approach to program development. Invitations to this meeting were to be “restricted to a nucleus of well-qualified key people who would provide adequate representation for both users and manufacturers.”15 For Hopper, this nucleus was easy to identify, for it coincided with the same distributed group of users, manufacturers, and programmers that she had helped to organize over the previous 8 years.
The more difficult task was to decide on an appropriate agenda. First and foremost, general agreement had to be reached among the meeting’s participants in regard to both the desirability and feasibility of a common business language. Desirability could probably be gauged at the 28 May meeting, but study groups would have to be created in order to make an educated decision concerning feasibility. These groups would have to specify the requisite elements of a common business language and identify the types of problems that such a general language would be able to handle.16
The idea team also faced difficult organizational problems. If a variety of subcommittees were formed to study feasibility issues, how would they be organized to foster effective communication? Would the sub-committees’ responsibilities overlap? How would consensus be determined? These and other questions would be answered at a two-day meeting in the spring of 1959.
On 28 and 29 May 1959, the Department of Defense hosted the organizational meeting of the Conference on Data Systems and Languages (CODASYL). Forty representatives from seven government agencies, eleven companies (users), and ten computer manufacturers attended. The computer manufacturers were Sperry Rand, IBM, Honeywell, RCA, General Electric, Burroughs, National Cash Register, Philco, Sylvania, and International Computers and Tabulators. Charles Phillips chaired the meeting, and Grace Hopper attended as a representative of Sperry Rand and as Phillips’s technical advisor.17 Hopper was impressed by both the number and the quality of the attendees: “I don’t think ever before or ever since have I seen in one room so much power to commit men and monies as I saw that day.”18
After discussing the feasibility of such an ambitious project, Phillips hoped to gain a sense of the proposed business language’s desired characteristics. Betty Snyder Holberton, Hopper’s longtime friend and confidant, offered this recollection: “Phillips . . . asked each of us to make some statement what we thought about the language plan. . . . I began to hear exaggerated claims, many unrealistic hopes, and I wondered what I would say.”19 Holberton and other professional programmers in attendance winced at the enthusiastic yet naive suggestions made by attendees with less coding experience. The group imagined a straightforward language that could be effectively applied to banking, utilities, insurance, production, and inventory control, not to mention medical and government applications.20 But Hopper viewed the same relaxed forum as an essential preliminary stage in the innovation process, a process that was consciously removed from the hands of professional programmers and included users and managers. The concerns of users differed considerably from those of professional programmers, as listed in a 1959 paper by E. J. Albertson (a member of CODASYL’s executive committee and a representative of the U.S. Steel Corporation):
• The majority of the group favored maximum use of simple English language.
• The majority preferred a language that was easy to use, even if somewhat less powerful.
• The majority agreed that the language should be initially open-ended and capable of continuous change.
• The majority agreed that the language should be problem-oriented and machine independent.
• All participants agreed that it was necessary to broaden the base of those who could state problems to computers.
• All agreed that the envisioned language characteristics should not be biased or limited by the limitations of present compilers.
The most significant disagreement concerned the use of mathematical symbols and algebraic expressions. Some participants believed that some business concepts were better expressed with mathematical symbols than with English words; other participants, including Hopper, felt that maximizing English expressions broadened the set of potential users, served a second role as program documentation, and made debugging easier.21
With some guiding principles in place, attendees focused their attention on how to create such a language. Three committees were formed, each with a defined set of objectives. The short-term committee, chaired by Joseph Wegstein of the National Bureau of Standards, would study existing business compilers, survey users about their experiences, and generate the initial specifications for an interim language. The intermediate-term committee, led by Hopper’s close friend Eugene Smith of the Bureau of Ships, would consist of two task groups; one would study the syntax of language and the other would study trends in business language. At the time of the May meeting it was believed that the more abstract knowledge gleaned by the intermediate-term committee would be incorporated into the final version of the language. The long-range committee, whose members were not determined during the May meeting, would then explore the fundamentals of all language and consider the merger of scientific and business languages into a universal computer language. The work of the three committees would be reviewed and approved by a CODASYL executive committee consisting of Charles Phillips, Joseph Cunningham (Air Force), E. J. Albertson (U.S. Steel), Gregory Dillon (Dupont), M. Grosz (Standard Oil), and the three committee chairs. Grace Hopper (Sperry Rand) and Robert Bemer (IBM) would serve as the executive committee’s chief technical advisors.22
THE SHORT -TERM COMMITTEE AND THE COBOL SPECIFICATIONS
The short-term committee was given a September deadline to come up with the specifications for an interim language, a deadline that experienced members of the committee knew was impractical from the onset. “To expect the short-range committee to develop a language and write the report in 3 months was gross optimism on the part of the executive committee,” recalled Betty Holberton (who had been a member of the committee). At best, initial findings would be reported in September, and the executive committee would have to accept the fact that it could not put such a strict deadline on the process of invention.
Having developed programming tools and languages in the past, Holberton instinctively knew that there was no such thing as an “interim” language. Manufacturers and users alike would implement a language only if they believed that it would be around for a while. To prove her point, Holberton turned to her old friend to supply the necessary data. “I asked Grace Hop
per if she could send me a cost estimate for implementing the compiler. She estimated that it would cost Sperry Rand $945,000 and 45½ man-years of effort,” she recalled. “In no way was this language going to be an interim solution. This language was it!”23 In the weeks after the initial meeting at the Pentagon, it became readily apparent to most members of the short-term committee that the burden of inventing the common business language rested squarely on their shoulders, despite the stated roles of the three committees.
The first round of meetings took place 7–9 July at a lakeside resort near Battle Creek, Michigan. Nora Taylor, another member of the short-term committee and a close colleague of Hopper’s, thought it amusing that committee members were instructed to bring bathing suits to the meeting. Though the majority of the committee’s time was spent wading through the surveys sent out to a multitude of computer facilities, the group did find time to enjoy the resort.
The survey of users verified that automatic programming had become both an accepted and a desired method. Half of the users surveyed were already employing Hopper’s FLOW-MATIC business language. Companies and organizations that used automatic programming reduced average training time of new users from 2 months to 2 weeks, and applications were up and running in 2–3 weeks rather than the more typical 2–3 months. Users cited time savings in coding, debugging, and testing, and compiled programs were considered about 80–90 percent as efficient as human-generated programs. The complaints cited most often were lengthy compile time, awkward language structure, and subroutine limitations. The most common business application requests were for payroll, sales statistics, pension plans, premium billing, inventory control, and production control.24