by Kurt W Beyer
After confirming user’s preferences, noting complaints, and identifying the most common applications, the short-term committee assigned a smaller statement language subcommittee to assess the strengths and weaknesses of existing automatic business compilers. The three main candidates for review were FLOW-MATIC, AIMACO, and COMTRAN, although Autocoder III, SURGE, FORTRAN, RCA 501 Assembler, Report Generator (GE), and APG-1 (Dupont) were also to be considered. As of July 1959, FLOW-MATIC and AIMACO were operational, while IBM’s Commercial Translator (COMTRAN) existed only on paper. Jean Sammet, a former UNIVAC programmer who supervised the advanced programming department at Sylvania, prepared a comparative study of language functions for FLOWMATIC I, FLOWMATIC II, COMTRAN, and AIMACO that was presented at the 22 July meeting in Washington. The untiring efforts of Sammet and others that summer earned the short-term committee the nickname “The P.D.Q. [Pretty Damn Quick] Group.”
The criteria the study used to judge the languages were naturalness of language, effectiveness in structuring data-processing problems, and ease of implementation. For example, when looking at language structure, the study considered how many individual sentences could be combined, whether a sentence could contain more than one function word, and to what extent the language could tolerate extraneous words and misspellings. Data management was also considered, especially data descriptions and the movement of data (input, output, sorting).25
AIMACO was an Air Force derivative of FLOW-MATIC, so it differed only marginally from the UNIVAC languages. COMTRAN’s specifications, on the other hand, included flexible GOTO and IF-THEN functions and a search function, and permitted programmers to use mathematical symbols instead of English when describing formulas. Roy Goldfinger, the author of the COMTRAN manual and a member of the intermediate-term committee, attended the statement language subcommittee’s meeting (held 22–24 July in Washington) to support his creation and to encourage the use of algebraic expressions.26
When word of the direction of the committee discussions got back to Grace Hopper, she responded with a heated memorandum to the short-term committee (dated 28 July 1959). Hopper reiterated that since 1954 Sperry Rand had led the industry in its effort to develop “problem-oriented, user-oriented languages” that aimed to use basic English as the chief input. “It is not the intention of Sperry Rand,” Hopper wrote, “to progress backwards by introducing mathematical symbols and banning adjectives, etc. etc.” Therefore, it was imperative that the committee focus on creating the specifications for a compiler suitable for the commercial customer, not for mathematicians and programmers. “If the language developed by the statement language committee continues in the direction in which it is headed,” Hopper threatened, “Sperry Rand will not implement it.” Instead, Sperry Rand would break from the CODASYL effort and would “supply its customers the first and the best use of English possible at any given stage of the art.” Hopper ended the memo with a caustic challenge to the short-term committee: “Sperry Rand would like to support the development of a common data-processing language, but suggests that such a language will probably have to be developed by people familiar with business data-processing problems and not by mathematicians and programmers.”27
According to Hopper, throughout the fall of 1959 the short-term committee took her advice to heart and used FLOW-MATIC as the blueprint for the new language’s specifications. In fact, Hopper asserted that entire sections of the FLOW-MATIC manual itself had been copied because of time constraints imposed by the executive committee and the DOD.28 The most significant concept that the short-term committee borrowed was the application of basic English to describe both data and the procedures to be executed.29 This meant that FLOW-MATIC-type operational verbs, sentence structure, and full alphanumerical descriptions of data (no abbreviations) found their way into COBOL. Jean Sammet, a member of the short-term committee, concurred with Grace Hopper’s claim that COBOL was highly influenced by FLOW-MATIC, though she also maintained that the languages were not one and the same.30
As for the other two languages reviewed by the short-term committee, little could be gained from AIMACO, itself a derivative of FLOW-MATIC. In 1958, Colonel Alfred Asch (a member of the short-term committee) and his programming team at the Air Force Air Materiel Command in Dayton had modified FLOW-MATIC to run on a UNIVAC 1105. At the time of the first CODASYL meeting, Asch was attempting to improve on the original by introducing limited portability. According to Sammet, the project was never completed once COBOL was accepted as the DOD standard.31
IBM’s Commercial Translator (COMTRAN), like many of the company’s other products, was “announced” to IBM customers and potential customers well before it was close to completion. The technique permitted the powerful firm to gauge the receptivity of the marketplace while the potential product was still in the design phase. To the dismay of IBM’s competitors, many customers rejected rival products on the promise that IBM would produce what it pledged.32 As of 1959, COMTRAN existed only as a series of specifications, but the short-term committee regarded it as a competitor to FLOW-MATIC. Much like FLOW-MATIC, COMTRAN was to be an English-based language, but its specifications included some notable differences, which were incorporated into COBOL’s design. These included a powerful conditional IF-THEN that enhanced the naturalness of the language (by making it unnecessary to write multiple JUMP or GOTO commands) and a more robust file-management system that included suffixing, searching, and layered data description.33
FACT AND THE POLITICS OF LANGUAGE STANDARDIZATION
In the fall of 1959, another business programming language was much farther along in the development process than IBM’s COMTRAN, yet its characteristics were not incorporated into the initial COBOL specifications. The creative mind behind FACT (Fully Automatic Compiling Technique) was Roy Nutt, who had developed the specifications for the language 5 months before the first CODASYL meetings. Nutt, who had worked on FORTRAN’s development while on loan to IBM from United Aircraft, was an extraordinary programmer with an ability to anticipate errors just by looking at the code.
Nutt and his associate Fletcher Jones (of the newly formed Computer Science Corporation) approached Richard Clippinger, the head of software development for the Honeywell 800 computer, concerning the construction of a powerful business data-processing language. Nutt’s design represented the most complex and robust computer language to date, requiring several hundred thousand instructions to complete.34
By October 1959 (according to Jack Strong, a member of the intermediate-range CODASYL committee), Roy Nutt’s FACT manual had found its way into the hands of members of the short-range committee and members of the intermediate-range committee. Serious programmers on both committees admired FACT for its flexible input/output system and its intuitive data-description and record-retrieval functionality. Built-in error-checking and information-compression capabilities impressed the intermediate-range committee to the extent that it passed the following resolution on 14 October 1959 by a vote of 15 to 1, with two abstentions:
IRTF II recognizes that the Honeywell Business Compiler represents the most advanced compiler specifications existent at this date, and recommends to the executive committee that the Honeywell Business Compiler specifications be the basis for the first stage Common Business Language.35
After the resolution vote, Jack Strong recalled, “we all went home, secure in our thoughts that significant improvements would be incorporated in the design of COBOL.”36 But much to Strong’s surprise, supporters of a FLOW-MATIC-based COBOL would overturn the intermediate-range committee’s resolution, leaving FACT, CSC, and Honeywell out in the cold.
Jean Sammet remembered that the intermediate-range committee resolution “had the effect of a major bombing” on the spirits of the short-term committee. The short-term committee was well along in defining its specifications by October 1959, and to scrap the work done thus far and make FACT the basis for COBOL was unthinkable. Sammet freely admitted that FACT was indeed the technically superior langua
ge by the fall of 1959. The language’s advantages, however, were diminished by the fact that its creators did not concern themselves with machine portability, nor did they build consensus among manufacturers and users.37
But not all motivations for blocking FACT in favor of FLOW-MATIC were so innocent. Howard Bromberg (RCA’s representative and a member of the original “idea team” that approached Charles Phillips) worked many hours with Sammet and the short-term committee to create COBOL’s specifications. At the same time, Bromberg fed technical data to his RCA team. “We kept about one week behind the committee,” he stated later. “RCA wanted to commercialize COBOL as a product to have a marketing edge.”38 By scrapping COBOL and starting over with FACT, RCA would lose both its technical and its economic advantage.
As tensions mounted and Honeywell threatened to develop FACT on its own, IBM’s commitment to COBOL began to waver. On the one hand, IBM, as the largest computer manufacturer, had much to gain from an easy-to-use common business language. Expanding access to computers via COBOL would increase the size of the hardware market. But because of IBM’s growing dominance within that market by 1959, there was a strong chance that COMTRAN, once operational, would evolve into the standard common business language. This hope was supported by the growing popularity of FORTRAN by the end of the 1950s. FORTRAN was the most widely used language on IBM equipment,39 and UNIVAC was planning a FORTRAN compiler for its next generation of computers, signaling the demise of Hopper’s MATH-MATIC.40
Mounting tensions among the manufacturers prompted one of the more colorful moments in the history of programming. Sometime during November 1959, a depressed Howard Bromberg was driving in New Jersey when he came across a place where cemetery monuments were sold. As he slowed the car, a child’s marble tombstone with the image of a lamb engraved on it caught his eye. Bromberg stopped the car, purchased the tombstone, and had the letters COBOL carved and gold-leafed below the lamb. Bromberg took the tombstone home, built a crate for it, and shipped it express to Phillips’s office in the Pentagon. Grace Hopper recalled that the tombstone was meant to remind Phillips of the precarious position in which the infant common business language found itself during the late fall of 1959: “COBOL is about to die, do something.”41 But according to Phillips, the tombstone represented a much different message. “Obviously,” Phillips recalled, “someone did not wish the COBOL program well, and was very kindly providing the chairman with a marker for the grave.”42
As the December deadline for technical specifications approached, a FLOW-MATIC-based COBOL had enough supporters to avoid an early grave. For one thing, Howard Bromberg’s connection to FLOW-MATIC ran deeper than the economic advantage accrued by RCA. Bromberg—a former member of Grace Hopper’s Computation Analysis Laboratory—had designed the RCA Automatic Programming Group in its image. “Having worked for Grace Hopper, I worked for RCA carrying her banner and using the techniques that she taught me,” wrote Bromberg.43 A closer inspection of the short-term committee’s makeup reveals a substantial number of Hopper protégés. Jean Sammet worked for Sperry Rand before going to Sylvania. Betty Holberton, Nora Taylor, and Mary Hawes were longtime colleagues of Hopper’s, and in particular Holberton and Hopper worked side by side to create the original programming department at the Eckert-Mauchly Computer Corporation. Colonel Alfred Asch was responsible for AIMACO, the Air Force language derived directly from FLOW-MATIC. Finally, committee members E. F. Somers, William Finley, and Dan Goldstein were all gainfully employed by Hopper at UNIVAC as of 1959.
The pro-FLOW-MATIC short-term committee approved the final specifications despite objections from individuals and organizations inside and outside CODASYL. The final report outlined the specifications for COBOL and insisted that it be the only common business language sponsored by CODASYL. No modifications of the language would be permitted except through consultation with a permanent COBOL maintenance committee whose initial membership, unsurprisingly, would be made up of members of the short-term committee.44
The final report also contained a letter from Honeywell rejecting the short-term committee’s findings. C. H. Gaudette, manager of Honeywell’s Automatic Programming Department, praised the short-term committee’s efforts and admired the collaboration of traditional competitors. Ultimately, however, the committee’s findings could not fulfill the needs of Honeywell’s business customers. Gaudette noted these deficiencies:
(1) The lack of a powerful output processor
(2) The inability to process card input files directly
(3) The absence of built-in sort routines
(4) The weakness of handling records of a highly variable nature
Naturally, these deficiencies could be corrected by making FACT, Honeywell’s business language, the nucleus of a revised COBOL.45
On 17 December 1959, the COBOL report was sent to the CODASYL executive committee for final approval. Much like the short-term committee, the Executive Committee was made up of people who were already familiar with FLOW-MATIC. E. J. Albertson (U.S. Steel) and Gregory Dillon (Dupont) represented UNIVAC customers. Eugene Smith (Navy) and Joseph Cunningham (Air Force) were friends of Hopper, who herself was the committee’s senior technical advisor. In January 1960, the executive committee approved the report of the short-term committee and assigned Betty Holberton to edit the document for publication. Changes that were made to COBOL from that point on were reviewed by the newly formed COBOL maintenance committee and approved by the executive committee. In April the official COBOL report was published and distributed by the Government Printing Office.
During the summer of 1960, RCA and the UNIVAC Division of Sperry Rand turned the April report into a functioning language. The first complete and accurate COBOL compilation (17 August 1960) was done on an RCA 501. By December 1960, RCA and Sperry Rand had confirmed the portability potential of the new language. The two companies each wrote a business application program in COBOL source code, interchanged the programs, and ran them successfully on a UNIVAC II and an RCA 501.46
The executive committee’s approval of COBOL (60) coupled with RCA and RAND’s efforts did not stop the controversy, and the battle over the standard raged throughout the year, prompting Jean Sammet to author a passionate plea for support. In a report dated 2 December 1960, Sammet wrote:
The lack of completion of final and complete COBOL specifications is due primarily to certain companies and individuals who have refused to work from the present language and prefer to “start all over.” These persons and their companies have done a great disservice to the COBOL effort by refusing to face the fact that the present specifications do exist, are being implemented, and are being used to write and run successful data processing problems.47
The main culprits were the manufacturers who had invested heavily in developing other English-based business languages, hoping instead that their own language would become the de facto standard. But according to Sammet, some users were also undermining the COBOL effort. In particular, companies and organizations that operated only one type of machine were less concerned with portability and hoped to see the establishment of a much more powerful language than that proposed by CODASYL. For instance, D. A. Nelson of the Lockheed Aircraft Corporation wrote to Charles Phillips shortly after the executive committee’s approval of COBOL to express “dissatisfaction with the lifeless camel of a language which is to become . . . the programming language for business data processing.” Nelson echoed the concerns of others, accusing the short-term committee of being “derelict in their duties” in failing to define a truly revolutionary language and instead offered one with a “scope barely wider than that of FLOW-MATIC.”48 Through the firestorm of opinions, Sammet expressed hope that “those who now oppose COBOL—either actively or passively—will stop condemning it long enough to give it a chance to succeed.”49
Grace Hopper running COBOL on a UNIVAC II. Courtesy of Computer History Museum.
COBOL: THE SUCCESS OF A PROGRAMMING LANGUAGE
In the years
that followed the publication of COBOL, scores of people predicted the demise of the experimental common business language. Their forecasts were not the unapprised views of a pessimistic few but rather the sound, informed observations of computer community elite, ranging from master programmers to computer industry executives. The critique of COBOL included complaints about the language’s semantic verbosity, its syntactical redundancy, and its overall lack of linguistic elegance. Mathematically inclined users cursed the upstart language’s inability to accept formulas and symbols. Astute programmers felt disconnected from the hardware of the machine. What was supposed to empower the user seemed to restrict programming creativity and hampered one’s ability to commune directly with the computer.
Even a few members of the short-range committee averred the claims of COBOL skeptics. The first compilers had some serious limitations, especially when conjoined with the available hardware of the day. State-of-the-art processors had difficulty dealing with the verbose, high-level language. Moreover, inefficient object code generated by the COBOL compilers used up internal computer memory, a precious resource that in 1960 was measured in dollars per byte. (At 1960s rates, today’s average laptop computer contains millions of dollars of memory.)
More surprising, criticisms of COBOL were aimed at the very process of its technical invention, a process that mirrored Hopper’s own style of distributed innovation. Many did not feel comfortable with the prospect of “innovation by committee,” including some who were part of that process. As Howard Bromberg stated, “little control was exercised over the development effort and the degree of guidance normally expected from a group of top-level technical managers was not forthcoming.” The COBOL process of invention did not correlate well with preconceived notions of invention. There was no heroic inventor like Thomas Edison or Elmer Sperry who passed down a singular guiding vision. Instead, “the COBOL committee was plagued by discontinuity of personnel and more often than not by a lack of talent.”50 Howard Bromberg’s comment concerning talent is particularly troubling, in view of the fact that committee members such as Betty Holberton, Jean Sammet, Mary Hawes, and Nora Taylor were the most experienced programmers in the business. None of them had a traditional pedigree of the kind more commonly held by their male counterparts in the industry, but few women of their generation did. Indeed, some COBOL skeptics concluded that the fruits of such an unstructured, female-dominated process could not be expected to survive, let alone flourish.