At the beginning Amid the Covid-19 pandemic, Up-to-date Jersey’s governor admitted an extraordinary fact: he was running out of COBOL programmers. State unemployment insurance systems were written in a 60-year-old programming language and needed updating to handle hundreds of thousands of claims. The problem was that few state employees knew how to do it. The crisis extended beyond Up-to-date Jersey, just one of many states dependent on these unwieldy systems. By scratchy calculation, COBOL inefficiency costs US GDP $105 billion in 2020.
You would think that after this Up-to-date Jersey would have replaced their system and that Covid was COBOL’s last gasp. Not quite. The state’s modern unemployment system brought many quality-of-life improvements, but on the other hand, it was made possible by a mainframe computer running an archaic language.
COBOL, brief for Common Business-Oriented Language, is the most popular computer language in history. Of the 300 billion lines of code written by 2000, 80 percent were in COBOL. It is still in widespread operate and supports many government systems such as motor vehicle registries and unemployment insurance; on any given day it can handle something of the order Worth $3 trillion financial transactions. I think of COBOL as a kind of digital asbestos, once almost ubiquitous, but now extremely, dangerously hard to remove.
COBOL was first proposed in 1959 by a committee composed of most of the American computer industry (including Grace Hopper). He called for the development of a “common business language specification for automated digital computers” to solve a growing problem: the cost of programming. Programs were custom-written for specific machines, and if you wanted to run them on something else, it meant an almost complete rewrite. The committee approached the Department of Defense, which welcomed the project.
The design of COBOL set it apart from other languages then and now. It was intended to be written in plain English so that anyone, even non-programmers, could operate it; symbolic mathematical notation was added only after considerable debate. Most versions of COBOL allow hundreds of words (Java only allows 68), including “is”, “then”, and “do”, to make writing easier. Some even argued that COBOL was intended to replace computer programmers, who held a sporadic position in many companies in the 1960s. They were masters of technology that most people could barely understand. The designers of COBOL also hoped that it would generate its own documentation, saving developers time and making it easier to maintain them in the long run.
But what did it mean to be legible anyway? Programs are not books or articles; these are conditional instruction sets. Although COBOL could reduce the complexity of a single line of code into a form that anyone could understand, this distinction broke down in programs consisting of thousands of lines. (It’s like an IKEA assembly manual: every step is simple, but somehow the whole thing still doesn’t fit.) Moreover, COBOL was implemented using a logic that had become despised: the GO TO statement, an unconditional branching mechanism that sent the user from one section of the program to another at lightning-fast speed. The result was “spaghetti code,” as programmers like to say, and self-documentation no longer made sense.
Many IT professionals had problems with COBOL from the beginning. Edsger Dijkstra famously hated the language, saying, “The use of COBOL is mind-numbing, so teaching it should be considered a crime.” Dijkstra also hated the GO TO statement, arguing that it made programs almost impossible to understand. There was a degree of snobbery about it: COBOL was often looked down upon as a purely utilitarian language intended to solve lifeless problems.
Jean Sammet, one of the early designers, saw it differently – language simply had the complicated task of representing complicated things like social security. Or, as another defender wrote, “Unfortunately, there are too many of these business application programs written by programmers who have never used structured COBOL well.” Good COBOL was indeed self-documenting, but much depended on the individual programmer. Fred Gruenberger, a mathematician at the Rand Corporation, put it this way: “COBOL in the hands of a master is a beautiful tool – a very powerful tool. COBOL, because it will be operated by a low-ranking official somewhere, will be a miserable mess.”