Common Language: Business Programming Languages and the Legibility of Programming

Ben Allen, Stanford University

Abstract—The English-like business programming language COBOL saw widespread use from its introduction in 1960 well into the 1980s, despite being disdained by computer science academics. This article traces out decisions made during COBOL’s development, and argues that its English-like appearance was a rhetorical move designed to make the concept of code itself more legible to non-programming management at computer-using companies.

Keywords—COBOL; business programming language; Grace Hopper

“And the LORD came down to see the city and the tower, which the children of men had builded. And the LORD said, Behold the people is one, and they have all one language; and this they begin to do; and now nothing will be restrained from them, which they have imagined to do.” —Draft COBOL specification cover page, 5 October 1959

The initial question driving this inquiry is how, or even whether, humanists should treat code. Is it something that we can meaningfully “read,” or is it only interesting for its technical capacity as a tool to define pieces of software? There is nothing new about thinking of code as a thing to be read for reasons other than its functionality. Most often, though, discussions within the humanities of the extra-functional capacities of code are framed in terms of aesthetics—the standards that programmers themselves use to assess code as an aesthetic object, and the role that code plays in “code poetry” and related creative productions. This approach is commonly associated with the small Critical Code Studies (CCS) movement; exemplary works in CCS include 10 PRINT CHR$(205.5+RND(1)); : GOTO 10,1 a series of readings of a one-line piece of BASIC code, Noah Wardrip-Fruin’s Expressive Processing ,2 which focuses on critical readings of the source code for digital games, and Mark Marino’s “Critical Code Studies,” the manifesto that launched the movement.3

Rather than approaching source code’s functionality beyond its capacity to define the behavior of machines in aesthetic terms, and rather than focusing on individual pieces of code, as is most common in Critical Code Studies, in this piece I approach programming language design itself as a tool for persuasion. The focus will be the design of the early English-like business programming languages, the most notable of which was COBOL. Although these languages would receive widespread disdain, especially from within academic computer science, and although often the verbose syntax of these languages often made them harder, rather than easier, to read and work with, I argue that the superficial resemblance between English and business programming languages was an effective tool for making the concept of programming itself more familiar to executives skeptical of incorporating computers into their business processes, and that this persuasive quality was valuable without regard for whether the English-like syntax granted any real insight into the working of the code.

Programming languages must be understood as historically situated artifacts, ways to describe machines that respond not just to the technical demands of digital computation, but also to the social demands of their use contexts. As I will argue, regardless of whether or not the English-like quality of business programming languages made it easier to write or read programs, the resemblance to English-language business writing made programming itself more legible to the people responsible for purchasing machines and hiring programmers. The outward appearance of the language functions as an invitation to use, regardless of how well that appearance reflects the language’s inner structure. As a result, it is worthwhile for humanists to read programming languages for their rhetoric, for the strategies a language deploys to persuade users to use it, with an eye toward who these strategies include or exclude.

English, French, and German Bit Patterns

In December of 1953, about a year after writing Compiling Routine A-0—the first piece of software given the name “compiler”—Grace Hopper presented her superiors at Remington Rand with a report on the feasibility of creating a programming language for data processing, a language that would feature English-language keywords and syntax rather than mathematical notation. Her reason for doing this was her belief that potential business users were alienated by notation schemes that resembled mathematics. As she would explain at the 1978 ACM SIGPLAN History of Programming Languages conference (henceforth HOPL-1):4

Working with the people that I had work[ed] with in data processing, I found that very few of them were symbol-oriented; very few of them were mathematically trained. They were business trained, and they were word-manipulators rather than mathematics people.

Hopper’s proposal for an English-like data processing language was dismissed out of hand:4

I was promptly told that I could not do that. And this time the reason was that computers couldn’t understand English words. Well, I allowed as to how I never expected any computer anywhere to understand anything; that all I intended to do was to compare bit patterns.

It was not until over a year after her first report that Hopper was allowed to write a formal proposal for a programming language using English-language keywords. She referred to this language as B-0, “business language zero.” By 1955, Hopper’s Automatic Programming Group was ready to demonstrate a pilot version of B-0 to Remington Rand management, in the interest of getting a budget for completing the full version—the largest budget the Automatic Programming Group had ever requested. At the time of the demonstration, the compiler could only recognize 20 keywords. Thinking that this limited prototype might not win funding, Hopper also prepared versions of the compiler that could recognize those same 20 keywords translated into French and German.

Remington Rand management was sufficiently impressed by the English-language pilot compiler to grant Hopper the budget request. They would go on to market B-0 under the name FLOW-MATIC—a name used over Hopper’s objections. FLOW-MATIC would in turn become the main influence on the business programming language COBOL, ultimately the most widely used programming language of all time. Remington Rand management was, however, distinctly disinterested in the French and German versions. As Hopper would describe the aftermath of the demonstration:4

Have you figured out what happened to that? That hit the fan!! It was absolutely obvious that a respectable American computer, built in Philadelphia, Pennsylvania, could not possibly understand French or German! And it took us four months to say no, no, no, no! We wouldn’t think of programming it in anything but English.

Hopper’s characteristic writing and speaking style often involved exaggerations and distortions for effect. Hopper biographer Kurt Beyer argues that her statements here with regard to the French and German compilers “serve more to highlight her sense of the dramatic rather than to represent management’s position,” which, as Beyer has it, was less about managerial disbelief that an American computer could parse German keywords, and more about managerial belief that the international market was not worth the expense of specialized language development.5 Nevertheless, the decision to avoid developing programming languages for the international market was not an obviously correct decision even at the time; as Hopper would note in a 1980 interview, Remington Rand was interested in selling computers to the NATO countries, and the availability of business programming languages using keywords in natural languages other than English could have resulted in increased sales.6

Hopper would analyze her failure to predict the behavior of the managers who received the demo in terms that highlight the differences between how programmers and non-programmers approached code as a concept:4

What to us has been a simple substitution of bit patterns, to management we’d moved into the whole world of foreign languages, which was obviously impossible. That dangerous, dangerous point of something that’s obvious, evident to the researcher, to the programmer—when it’s faced by Management, is out of this world. It was nothing but a substitution of bit patterns, yet to management it was a move into all the foreign languages.

Later in her address, Hopper makes a telling statement about the relationship between business programming languages and natural language:4

The fact that we could substitute those French and English words means that it was never anything but a code. It was not a language. Because the fact that we could take the words of those statements and substitute French words, German words, or anything else, meant that it was not a true language. It was actually a code.

For Hopper, as for UNIVAC itself, programming language keywords were just labels given to bit patterns, labels that were freely interchangeable between each other. But when labeled in certain familiar ways, these bit patterns could become a source of budget increases. When implemented and marketed to customers, not as bit patterns but as things that look like English, they could result in sales. When they displayed just enough flexibility, they moved the line of what could get funding. When they displayed too much unexpected flexibility, they lost funding. Keywords were just a code, just bit patterns—but what they looked like was, at times, more important than what they were.

Hopper kept a copy of her original rejected 1953 proposal to create an English-like language. As she explained at HOPL-1:4

I keep it with me […] to remind me that at any given moment in time there’s always a line out here, and that line represents what your management will believe at that moment in time. And just you step over the line and you don’t get the budget.

In 1953, English-looking programming languages were on the wrong side of the line separating what management was willing to believe from what management was not willing to believe. In 1955, English was on the right side—but French and German were out.

Academics against English-Like Programming

FLOW-MATIC was far and away the main influence on COBOL—and COBOL was likely the most widely used language of all time, with one estimate made at the turn of the millennium estimating that of the roughly 300 billion lines of running code in the world at the time, 240 billion of them were written in COBOL.7 This code mostly defines business infrastructure—payroll programs, bank software, airline reservation systems—unflashy applications running on old machines, programs that are slow, but extremely stable. However, the mismatch between what COBOL code looked like—English-language sentences—and how it worked provoked disdain and contempt from academic computer scientists. To take one particularly harshly worded example, consider Turing Award winner Edsger Dijkstra’s denunciation of the language:8

With respect to COBOL you can really do only one of two things: fight the disease or pretend that it does not exist. Most Computer Science Departments have opted for the latter easy way out […] The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offence.

Dijkstra was famously cantankerous, but also quite influential—for example, his “Go To Statement Considered Harmful” almost singlehandedly resulted in the anathematization of an entire programming language construct.9 Whereas in the case of go to statements Dijkstra’s disapproval was enough to shift the practices of the field as a whole, in the case of COBOL he was simply expressing the preexisting beliefs of the field, although in a particularly florid style. For a survey of academic disdain of COBOL, see Ben Shneiderman’s “The Relationship between COBOL and Computer Science.”10

Contemporary to the development of the earliest English-like programming languages, John McCarthy, creator of LISP, dismissed the idea that there was any value in making a programming language resemble English. His 1957 “Proposal for a Compiler” makes reference to advertising for FLOW-MATIC:11

Some programming systems for business use have been advertised as allowing the programmer to write in English. It seems to me that these claims are somewhat fraudulent. It is, of course, easy to make a system in which the instructions are English sentences […]. However, to really be able to claim that English is being used as a programming language, one would have to be able to accept any reasonable synonym for a sentence, and even more important one would have to have the facility available in English of being able to define new terminology. One may hazard a guess, that were such a facility available, the programmer would quickly use it to establish a jargon that would look almost as incomprehensible to the uninitiate as the present programming languages.

These statements from McCarthy are entirely accurate—but they fail to engage with the persuasive aspects of language design. Regardless of whether a superficial resemblance to English could result in genuinely readable code, this resemblance served a real purpose, as a means to convince computer-using organizations to trust both programmers and the tools they produced. This strategy was not necessary for scientific computing languages, since the purchasers and user base were expected to understand what a computer program was. Moreover, it would not have been effective in that domain, since in that context mismatches between what a language looked like and how it behaved would be understood as a flaw. But in the business programming domain, adapting language to its social context was at least as important as adapting the language to the machines on which it ran, regardless of whether the appearance of the language’s behavior matched the underlying behavior of the system.

COBOL was met with a measure of skepticism from business programmers, though not the outright rejection that the language would receive in academia, and not for the same reasons. In March 1961, Jean Sammet, who served on the committee that designed COBOL, found it necessary to write a letter to business-programming journal Datamation addressing the concern that the public had been misled by this marketing—though the focus of her letter is not on the promises of legibility made in COBOL advertisements, but instead COBOL’s promise of portability between machines.12 In the September 1961 issue of Datamation , RCA’s director of Automatic Programming, Howard Bromberg, published a piece, titled “What COBOL Isn’t,” wherein he noted that “COBOL isn’t the answer to the programmer’s prayers or the manager’s dreams” and stated that “the notion that installations may exist with a COBOL compiler and without individuals who are knowledgeable concerning machine programming or the details of the computer is utterly without foundation.”13 Nevertheless, Bromberg strongly recommended COBOL for use, and described the English-like quality of COBOL as an aid to documentation even if it did not allow for non-programmers to write code.

Language and Control

Marketing materials for Remington Rand’s UNIVAC computers described FLOW-MATIC as a tool that would allow programmers to program more quickly, with fewer clerical errors, and with less programmer training required (see Figure 1 and Figure 2). Highlighting the resemblance between English-language problem statements and FLOW-MATIC code, one 1958 UNIVAC handbook would claim “for the FLOW-MATIC programmer, the job is almost finished as soon as it is stated.”14

Graphic: Figure 1. Problem statement in business English.

Figure 1. Problem statement in business English.

Graphic: Figure 2. Problem solution in FLOW-MATIC code.

Figure 2. Problem solution in FLOW-MATIC code.

The handbook promotes FLOW-MATIC as a tool to make programming easier, but more than this describes FLOW-MATIC as a tool to make programming easier to control . “Since English is used,” it states, “Management can completely understand and therefore control what is to be done in their operations.”14 This is better understood as marketing fluff than as an accurate technical description of the capacities of the language. At the very least, the claim that FLOW-MATIC would allow managers complete control over the process of code production is an overstatement. It is worthwhile, though, to note that the appearance of the language allowed managers to more easily understand what sort of thing a program was, even if it did not allow non-programmers to completely understand what any given piece of code actually did. Although English-like business programming languages aren’t language —although they are, in Hopper’s terms, “just code,”—their language-like appearance is persuasive. Although FLOW-MATIC did not allow managers to “completely control” programmers, it nevertheless allowed managers to understand programmers as part of a hierarchy, at least theoretically capable of being understood and controlled by management.

Common Business Language

FLOW-MATIC inspired other computer manufacturers and users to design English-like business programming languages for their own machines. By 1959, IBM had begun development on COMTRAN, Honeywell was in the early stages of designing FACT, and the United States Air Force was working on its own AIMACO language. Hopper played a key role in the organization of a conference in April 1959 at which the idea of a common business programming language, implemented across all machines, was broached. Although no one manufacturer would get an advantage through having the “best” language, all computer manufacturers would benefit from the existence of a language that could make all computers easier to program. Users would benefit from not having to train programmers to use different languages for different machines. Moreover, a common language could, at least in theory, allow programs to be written for one machine and run on another. The attendees at the April 1959 meeting resolved to ask the US Department of Defense for support for a common business language; Charles Phillips, the Department of Defense’s director of data systems research, enthusiastically welcomed the idea and arranged for the Pentagon to host a pair of meetings of what would be called CODASYL—short for “Conference on Data Systems Languages”—in May of that year.

COBOL, the language that would be developed as a result of the CODASYL meetings, is significant as the intersection between two early efforts to produce “common language” programming tools. As we have seen, COBOL was “common language” in that it was designed to mimic English, with each statement in the language also being a grammatically correct English-language sentence. It was also a common language in that it was meant to be common across machines, designed to be implementable on every digital computer available at the time. It is worthwhile to note that the Department of Defense, and particularly Charles Phillips, would play an active role in ensuring the adoption of COBOL across all machines. In particular, shortly after the language’s specification was released, Phillips announced that the Department of Defense would not be interested in purchasing or leasing any computer that lacked a COBOL compiler unless the manufacturer could demonstrate that the machine’s performance would not be enhanced by the presence of COBOL.15 Nevertheless, the Department of Defense’s efforts to ensure the availability of COBOL did not by themselves guarantee the language’s success; consider, for example, the later case of the Ada programming language, which likewise was mandated on military machines, but which received nothing like COBOL’s widespread non-military use.

The two senses of “common language” in the name COBOL reflects the contested status of the word “language” in mid-20th-century digital computing. David Nofre, Mark Priestly, and Gerard Alberts, in their “When Technology Became Language: The Origins of the Linguistic Conception of Computer Programming,” document how the language metaphor for programming shifted over the course of the 1950s. In the first half of the decade, the language metaphor was primarily used in cybernetics-inflected discourse, discourse that tended to anthropomorphize computers.16 By the beginning of the 1960s, the language metaphor had developed a new and subtler use, becoming a conceptual tool to reify code as something distinct from the machines that code ran on. Whereas the early-50s use of “language” in digital contexts talks about programming languages as instruments for communicating with an anthropomorphized machine, the late-50s idea uses the language metaphor to present programming as an object of knowledge in itself, separate from any machine.

COBOL, as the first cross-platform data-processing language, is a significant part of the project of unbundling the idea of programming from the machines programmed. In this sense it is very much like ALGOL, the first cross-platform scientific language, developed at roughly the same time as COBOL. However, unlike ALGOL—which used a relatively conventional algebraic notation—COBOL also leans heavily on the earlier, anthropomorphized version of the language metaphor. If we understand code as the language used to talk to anthropomorphized machines, COBOL can be thought of as an attempt to make programming easier through “teaching” those machines an English-like language. This version of the language metaphor is recruited into and reinforced by the language’s design, with COBOL’s appearance when skimmed helping non-programmers recognize that code can be understood as something like language, even if the underlying code did not work like language—even if it was, as Hopper described FLOW-MATIC code, “just bit patterns.”

Stopgap Language

At the two initial meetings of the CODASYL group it was agreed upon that the organization should establish three committees for the development of COBOL. First was the Short Range Committee, which was tasked with reporting back by the end of 1959 with a “stopgap language” to be used for the next year or two—although there was a measure of controversy over whether the Short Range Committee was really meant to design a language, or if it was originally intended to just produce a set of recommendations. Intermediate and Long Range committees were also set up, tasked with developing more thoughtfully designed versions of a common business language for long-term use.

The need for the Short Range Committee’s “stopgap” was the most pressing issue for the organizations that had sent representatives to the CODASYL meetings. Given that the Short Range committee was the only group that could meet the primary desire of the group as a whole, it is in retrospect understandable that the Short Range committee ended up being the only one to produce a language. In fact, the Long Range Committee never met, and the Intermediate Range committee only met twice. According to Sammet, the second and final meeting of the Intermediate Range Committee, in October 1959, resulted in the committee finding the language proposed by the Short Range Committee to be strictly worse than FACT, Honeywell’s business language under development. The Intermediate Range committee’s strongly worded recommendation was that the work done to that point by the Short Range Committee should be scrapped and then restarted using FACT as the base; this recommendation, however, was only formally considered by the CODASYL executive committee after the Short Range Committee’s report defining COBOL had already been finalized.17

There may have been some opportunism at play among the members of the Short Range Committee in designing a language at all. According to minutes of the two meetings of the Intermediate Range Committee, their understanding was that the Short Range Committee would prepare a list of recommendations rather than a proposal for a complete language design. Sammet states in her “Brief Summary of the Early History of COBOL” that the official mission of the Short Range Committee was to “ explore a problem-oriented but machine-independent language”18 based on the extant business programming languages. The emphasis here is Sammet’s.


Stepping back for a second: what does it mean for a programming language to look like English? Moreover, what did “looking like English” mean to the developers of COBOL? We have seen a series of claims about the potential for English-like programming languages: that it would allow for code to be self-documenting, that it would allow for managers to understand and control the process of programming, that it would reduce the expense of programmer training, that it would, at the very least, be attractive to businesspeople unused to algebraic notations. What benefits did the developers themselves see in COBOL’s English-like quality?

The final draft of the April 1960 CODASYL report that contained the first full version of the language contains the sentence:19

The COBOL system allows the user to prepare his specifications for the problem solution in the language most natural to him—namely English.

Earlier revisions, though, spent some sentences after that explaining a few of the differences between COBOL and English (emphasis in original):19

The COBOL system allows the user to prepare his specifications for the problem solution in the language most natural to him—namely English. One of the principles adopted in the development of COBOL is that everything in the language would be correct English (however, this does not mean that everything which is correct English is meant to be a part of the COBOL System or acceptable to a COBOL compiler.) In a few cases it was necessary to violate this principle to allow the inclusion of certain features which could not be handled by normal grammatical rules.

A tension is at play between these two revisions—between the marketable claim that COBOL would allow the user to prepare specifications in English, and the more technically accurate clarification that, although for the most part COBOL was correct English, this did not mean that everything in English was in COBOL.

As noted above, one of the chief complaints about COBOL from programmers, especially academic computer scientists, is that the verbosity required to mimic English language sentences did not grant readers any real clarity into the working of the code. Moreover, writing working code while adhering to the constraint of looking like English can be quite difficult. To take one small example, the use of a period to end each COBOL statement made debugging COBOL conditional statements difficult; when writing nested code IF statements a lone “.” is easy to misplace. And some of the shims put into the language to make English resemblance easier more often distract from the meaning of the code. Consider COBOL’s “noise words” (sometimes less pejoratively called “optional words”). These reserved words bear no meaning to the compiler—they are discarded before compilation—but were included to make the construction of grammatically correct sentences easier. “AT” and “ARE” and “WHEN,” for example, are included as noise words. One early draft of the language even included “DOLLAR” as a noise word.19 Because these words are reserved, they cannot be used as variable names—and so despite whatever convenience they grant for the construction of valid English-language COBOL statements, they also present a pitfall to programmers who may be unaware that certain commonly used words are off-limits because they are predefined to mean nothing.

The uncomfortable mismatch between marketability and technical accuracy here is not meant to indicate that the Short Range Committee intended to deceive potential COBOL users. The course of the development of COBOL indicates that there were genuine efforts to produce a language that documented itself through its resemblance to English—although often these efforts were abandoned or scaled back. For example, unlike most other languages, at the outset of COBOL development the language did not contain any capacity to leave comments. This indicates that the committee members thought it was at least worth the effort to see if English-like syntax could be enough for COBOL code to be legible enough to serve as self-documentation. It was not until midway through the development of the language specification, in fall 1959, that comments were introduced. A report prepared by Sammet, titled “POINTS OF GREATEST CONTROVERSY,” explains the decision to include comments in relatively terse terms. Whereas most of the “points of greatest controversy” required fairly long technical responses, the question of the need for comments was raised and addressed as follows:20



Although the use of English-language words for keywords made programming in grammatically correct English sentences possible, following the logic of the code as a whole (rather than just reading individual lines) turned out in practice to be at least as difficult as following the logic of code written in terser, less English-like languages. And so, the ability to leave comments in English—or whatever other natural language the programmer preferred—was necessary, just as it is necessary in all other programming languages.

Sperry Rand Threatens to Leave CODASYL

Likely none of the principal decision makers in CODASYL believed that computers could be literally programmed in English, in the sense implied by marketing materials. Although valid COBOL could look like English, this did not mean that all valid English would therefore be valid COBOL—and so, despite marketing claims about reducing the need for “highly skilled” programmers, there was never an expectation that non-programmers would be able to program in COBOL without any training. Nevertheless, maintaining the image of English-ness was important enough that midway through fall 1959, Sperry Rand—represented by two of Hopper’s subordinates in the Automatic Programming Group—threatened to pull out of CODASYL altogether if COBOL allowed for mathematical notation instead of keywords like MULTIPLY and ADD, or even if the specification simply allowed for mathematical symbols to be used alongside words like MULTIPLY and ADD. As expressed in a sharply worded memo, the Sperry Rand line was as follows: “It is the clear aim of Sperry Rand to ultimately design compilers which accept good English as their input. It is not the intention of Sperry Rand to progress backwards by introducing mathematical symbols.”21 The memo concludes by stating:21

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 be mathematicians and programmers.

Although the memo is unsigned, it is difficult not to see the marks of Grace Hopper’s own blunt writing style in this passage. Why, though, did Sperry Rand find it so objectionable to include the option of saying “+” or “*” to indicate addition or multiplication? Hopper had, at this point, been selling the idea of English-looking programming to UNIVAC customers for four years, and understood the differences between how a programmer trained in mathematics and a non-programmer trained in business processes saw a page of code. Although to a programmer these two different notation schemes are interchangeable in that they represent the same underlying commands, implemented through the same underlying bit patterns, to the manager a page containing + and * is math, and thus less inviting than a page with formulae written out in English using ADD and MULTIPLY.

In his May/June 1960 Datamation letter, Charles Phillips, while explaining that COBOL would be implemented soon, described the virtues of COBOL as follows:22

At this point we are encouraged to believe that computer users looking for the advantages of a common language, basically in English, which is oriented toward business data processing problems, is open-ended and essentially independent of any make or model of data processing equipment, can begin to use COBOL very soon.

Much of the meaning of Phillips’s description of the language hinges on the word “basically” before “in English.” Packed tightly inside this single word is all the tension between COBOL’s function as code and its appearance as language. COBOL was not English—it simply appears as if it were “basically in English.” But appearance matters.

Compromises Related to Portability

We have seen a few of the ways that COBOL is not the same as natural language, the ways that (despite the best efforts of the Short Range Committee) it proved impossible in practical terms to craft a computer programming language wherein programs document themselves by describing themselves in English. At the very least, we can safely say that COBOL differs from English, and cannot be read as if it were English.

Likewise, though, COBOL is different from actual executable code on any of the machines on which it was implemented. COBOL was intended to be interoperable across every machine then in use. Because of this, we cannot simply say that COBOL has to differ from English because of constraints imposed by “the” machine it is running on. This is because there is no one real machine imposing those constraints. Instead, the programming language, like all programming languages, represents a particular agreement on what a digital computing machine can or should be.

In the case of COBOL, the terms of this agreement were quite literally negotiated in the CODASYL committee meetings, under the constraints provided by extant machine architecture and by competing business interests. Some of the negotiations involved determining how well certain concepts could or could not be implemented (noise words without comments, for example), or figuring out what features were or were not desired (formula notation to go along with English-like notation, for example). Some decisions involved the more straightforwardly political problem of implementing or not implementing features that existed on only some of the machines on which COBOL would be used. Sammet’s chief example of this is the decision not to implement a command to read a tape in reverse. This operation would be easy on machines that were actually physically capable of reading tape backwards. However, it would be slow and inefficient on machines that could not do so. On these machines, COBOL could only implement the command by having the computer rewind the tape a set amount, read it forward, rewind the tape again, and so on. Sammet explains:17

This potential READ REVERSE command was finally thrown out on the grounds that although it could be logically implemented by everybody, the penalty in efficiency was too great on machines without such a basic command.

A powerful command on some machines was thus left out of COBOL because of that command’s non-universalizability. Although READ REVERSE is something that specific machines could do quickly, it was not something that could become part of what the agreed-upon machine could do quickly.

The READ REVERSE decision was not a one-off—compromises to performance in order to ensure that no manufacturer won an advantage over any other were common. At HOPL-1, Sammet noted that COBOL-60 allowed for expressing values up to 18 decimal digits in precision. This number was chosen not because it was optimal for any particular machine, but instead “for the simple reason that it was disadvantageous to every computer thought to be a potential candidate for having a COBOL compiler.”17 COBOL, here, must differ from all the machines it runs on, because only a model that fit awkwardly on every computer was acceptable for all computer manufacturers.

Technical compromises—the demand that different machines with different features all act like an imaginary standardized machine—were necessary to establish a common computer programming language. And syntactical compromises—a superficial resemblance to English that does not illuminate the underlying logic of the code—were necessary to get that common language into actual use.

COBOL as Boundary Object

CODASYL itself did not actively market COBOL. “Some More Facts about COBOL,” an unsigned article in the March/April 1960 issue of Datamation , notes that the minutes of a 12 February 1960 meeting of the CODASYL Executive Committee indicates that the committee “rejected a proposal to establish a group responsible for COBOL marketing, public relations, publication and publicity.”22 The minutes state that

“The Committee believes it has inherent responsibility for such limited publicity as may be necessary together with problems of public relations and publication. It is strongly opposed to the idea that a ‘marketing attitude must pervade everyone’s thinking’ to gain acceptance of COBOL. The committee believes that a ‘marketing attitude’ would be detrimental and that any attempt to commercialize COBOL must be avoided.”

Despite this official stance against a “marketing attitude” and against commercializing COBOL, a spate of COBOL-related ads quickly appeared in the following issues of Datamation , and across the computer industry press more broadly. These ads made varying and at times inaccurate claims about COBOL’s potential to make the work of programmers more legible and trustworthy to management. Take, for example, the RCA advertisement in the September/October 1960 Datamation in Figure 3.

Graphic: Figure 3. RCA COBOL Narrator advertisement, Datamation , July/August 1960 .

Figure 3. RCA COBOL Narrator advertisement, Datamation , July/August 1960 .

This advertisement neatly showcases all of the key promises about the potential of COBOL. It is presented as not just English-like, but “plain-English.” It is described as both easily read and easily understood. It makes programming less mysterious. And it is described as a means for “direct management supervision of procedures and records.” None of these claims are true, at least not in terms that Edsger Dijkstra would recognize. Note that the advertisement touts the Department of Defense’s role in leading COBOL’s development as supporting evidence for the quality of the language, but foregrounds the language’s English-like quality over its pedigree.

Datamation was aimed at an audience with widely varying levels of technical knowledge. Although the articles themselves typically assumed a relatively high level of sophistication about programming, and although advertisements for computer hardware tended to be technically detailed and technically accurate, advertisements for software made no assumptions whatsoever. Well into the 1960s, Honeywell ran advertisements for its software that opened with an explanation of what software was. Almost all advertisements for COBOL deployed anthropomorphic metaphors; for example, even the relatively staid ads from IBM described COBOL as a “ghost writer” for code. We can, along with the academic computer science consensus, understand these ads as deceptive or misleading. But we can also interpret them as a tool to bridge distinct discourse communities.

Nathan Ensmenger, discussing the work practices of 1960s and 1970s programmers in his “The Multiple Meanings of a Flowchart,” takes up the idea that the flowcharts that programmers of this period were trained to produce were valuable as “boundary objects,” even if they were not particularly useful in practice as in their intended use as design documents, or as “blueprints for code.”23 A boundary object (a term originally used by Susan Leigh Starr and James Griesemer) is an “artifact that simultaneously inhabits multiple intersecting social and technical worlds,” an “object flexible enough in meaning to allow for conversation between multiple communities.”23 In the case of flowcharts, their relative uselessness as design documents was offset by how they could flexibly acquire new meanings and roles over time and across groups—as after-the-fact documentation, or as implied contracts meant both to guarantee that the code requested by the client got written and also to make the client agree to a clear feature set ahead of time.

Remington Rand made explicit the connection between English-like programming languages and flowcharting practices through the name it assigned Hopper’s first English-like language: FLOW-MATIC. This name encouraged customers to conceptualize the language as a tool to automatically produce code from flowchart labels (see Figure 4 and Figure 5). Beyond the name, early promotional materials in part argued that FLOW-MATIC was valuable because it would make flowcharts themselves clearer:24

The English-language pseudo-code of Flow-Matic causes the Univac system to automatically compile and write its own compiler code. Thus, both flow charts and codes are made intelligible to the non-programmer as well as to the programmer.

The English-like appearance aimed at by early business programming language designers can be thought of as an attempt to make every piece of code into a potential boundary object, both meaningful to programmers (as working code) and also meaningful to non-programmers (as something like a piece of English-language writing).

What academics would perceive as COBOL’s perverse verbosity is the result of the language’s development in a context wherein the people to whom computer hardware and programmer time were sold were both unfamiliar with software and skeptical of trusting the implementation of vital business processes to code written by programmers, who themselves seemed out of place as decision makers in business hierarchies. They seemed out of place because of their mathematical training, out of place because they primarily commanded machines instead of people, and often because of their gender, since a significant proportion of the earliest programmers were women. COBOL’s English-like character did not make individual COBOL programs easier to read or write. But by promoting the idea that giving instructions to a machine is something like writing a business memo, COBOL made the field of programming itself more legible, at least to English-speaking executives.

Graphic: Figure 4. Assembly language flowchart.

Figure 4. Assembly language flowchart.

Graphic: Figure 5. FLOW-MATIC flowchart.

Figure 5. FLOW-MATIC flowchart.

Common Natural Language

It is worth ending by recalling the moment at the very outset of business programming language development—the presentation where Grace Hopper showed Remington Rand management a version of her business language compiler that could handle commands not just in English, but also in French and German. Whatever the reason for management’s dismissal of the non-English versions, the decision to reject non-English languages as valid for programming computers was at this point arbitrary—it was a decision that could have been decided otherwise. As a result of this decision, the invitation to use offered by FLOW-MATIC’s syntax—and eventually inherited in COBOL’s syntax—was offered only to English speakers. And although today COBOL is not widely used for new software, English is nearly inescapable—all widely used programming languages feature keywords derived from English, and the use of English-language variable names and even comments is preferred worldwide. The role played by English as a common language for computing resembles the role played by English as a common language for science and mathematics, but the case of COBOL illustrates how the rise of English in computing does not simply reflect or echo the rise of English in science. It is instead tied up in a set of business decisions about the relative marketability of programming languages, and the perceived need to make the concept of computer programs seem more familiar to English-speaking business executives.25

Although the decision to converge on a common natural language—English—was contingent in 1955, attempting to develop programming languages based in other languages is now quite difficult—much more difficult than it was for Grace Hopper. Designing a useful programming language no longer means simply designing a notation system for describing the actions of a machine. Instead, it requires developing interfaces to several decades’ worth of accreted code, code written largely in English-like notation schemes. Take, for example, Ramsay Nasser’s experimental Arabic-language programming language قلب.26 Although all the keywords in قلب are in Arabic, in practice قلب code tends to be a difficult-to-read mixture of Arabic and English. This is because most programs must call on libraries of preexisting code for things like displaying windows and rendering graphics—and these libraries are all in English-based code.

As Hopper observed after her first business-programming language demonstration, the fact that the English-language keywords could be swapped out for French and German ones indicated that the resemblance to natural language was superficial, that it was “just a code” from the perspective of the computer and from the perspective of the programmer. But the task of creating a common business programming language involved more than just implementing the language on all digital computers then in use. It also involved adapting the language to its social context. Just as technical compromises were required to implement the language across machines, syntactical compromises were required to fit the language into its context, to invite potential users to use it. And decisions made about who to invite to use a language and who to disinvite—English-speaking executives, but not French- or German-speaking ones—can themselves harden into technical constraints over time. COBOL is no longer the common language for business computing that it was in 1965, 1975, or 1985. But in a sense, English remains the common language of computing.