At the beginning of Covid-19 pandemic, the governor of New Jersey made an unusual admission: he was short of COBOL developers. The state’s unemployment insurance systems were written in a 60-year-old programming language and needed to be updated to handle hundreds of thousands of claims. The problem was that few government employees knew how to do this. And the crisis has moved beyond New Jersey, one of many states that relied on these heavy systems. By Rough Calculation, COBOL Inefficiencies Cost U.S. GDP $105 billion in 2020.
You’d think New Jersey would have replaced its system after that – and that Covid was COBOL’s last gasp. Not quite. The state’s new unemployment system came with a number of quality of life improvements, but in the background this was still made possible by a mainframe computer running the old language.
COBOL, short for Common Business-Oriented Language, is the most widely adopted computer language in history. Of the 300 billion lines of code written in 2000, 80% were in COBOL. It is still widely used and supports a large number of government systems, such as motor vehicle registries and unemployment insurance; on any given day it may manage something on the order of Worth $3 trillion financial transactions. I think of COBOL as a kind of digital asbestos, once almost ubiquitous and now incredibly, dangerously difficult to eliminate.
COBOL was first proposed in 1959 by a committee comprising most of the American computer industry (including Grace Hopper). It called for “specifications for a common commercial language for automatic digital computers” to address 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 involved almost a complete rewrite. The committee contacted the Department of Defense, which welcomed the project.
COBOL’s design set it apart from other languages past and present. It was supposed to be written in simple English so that anyone, even non-programmers, could use it; symbolic mathematical notation was added only after considerable debate. Most versions of COBOL allow the use of hundreds of words (Java only allows 68), including “is”, “then”, and “to”, to make writing easier. Some have even said that COBOL was intended to replace computer programmers who, in the 1960s, held a rarefied place in many companies. They mastered technology that most people could barely understand. COBOL’s designers also hoped that it would generate its own documentation, saving developers time and making maintenance easier. in the long term.
But what did it mean to be readable? Programs are not books or articles; they are conditional sets of instructions. While COBOL could distill the complexity of a single line of code into something everyone could understand, this distinction broke down in programs with thousands of lines. (It’s like an Ikea assembly manual: any given step is easy, but somehow the problem still doesn’t work out.) Additionally, COBOL was implemented with a piece of logic that came to be despised: the GO TO statement, an unconditional branching mechanism that took you from one section of a program to another. The result was “spaghetti code,” as developers like to say, that made self-documentation irrelevant.
Many IT professionals have had problems with COBOL from the start. Edsger Dijkstra hated it, stating: “Using COBOL paralyzes the mind; its teaching should therefore be considered a criminal offense. » Dijkstra also hated the GO TO statement, arguing that it made programs almost impossible to understand. There was a certain snobbery: COBOL was often seen as a purely utilitarian language intended to solve boring problems.
Jean Sammet, one of the original designers, saw things differently: language simply had the complicated task of representing complicated things, like Social Security. Or as another advocate wrote: “Unfortunately, there are too many such business application programs written by programmers who have never benefited from well-taught structured COBOL. » Good COBOL was indeed self-documenting, but much of that depended on the specific programmer. Fred Gruenberger, a mathematician at the Rand Corporation, put it this way: “COBOL, in the hands of a master, is a magnificent tool, a very powerful tool. COBOL, if handled by a low-level employee somewhere, will be a miserable disaster.”
Of course, none of this has stopped the widespread adoption of COBOL. It certainly helped that the Department of Defense took the step and required COBOL compilers in most of the machines it ordered. At the height of the Cold War, no computer manufacturer wanted to miss out on those federal contract dollars. Ultimately, COBOL achieved two of its most important goals: it was truly machine-independent and could proliferate rapidly. Its reliance on fixed-point, not floating-point, arithmetic (if you know it, you know it) made COBOL ideal for financial applications, which is why it’s everywhere in the financial industry.
But as New Jersey learned in 2020, updating COBOL for the modern era presents real challenges. Sammet admitted a key error in the initial design: no “parameterization.” Different parts of a program were divided into modules, but they couldn’t pass data to each other, so they had to share everything, which meant that changes in one place could affect the entire program. Or make millions of dollars disappear in a flash. Or take away people’s Social Security payments.
Today, companies like IBM trying to sell COBOL conversion tools which are powered by generative AI. (At one point, DOGE promised to use one of these tools to completely rewrite the Social Security Administration code base in a few months. The effort seems to have blocked.) But we might be caught in a bind. Simply converting COBOL to Java, for example, results in “JOBOL”, a confusing hodgepodge that mimics the structure of COBOL but without any readability. I’m not convinced by many of these AI tools. As with COBOL, they promise streamlined efficiency that is accessible to everyone. Look what happened there.