COBOL is the asbestos of programming languages

Early in After the COVID-19 pandemic, the governor of New Jersey made an unusual admission: COBOL developers had run out. 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 is that few state employees know how to do this. The crisis has gone far beyond New Jersey, which is just one of many states that have relied on these unworkable systems. By one rough calculation, COBOL inefficiency cost US GDP $105 billion in 2020.

You would think that New Jersey would have replaced its system then, 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 on the backend, it was still possible thanks to a mainframe running the old language.

COBOL, short for Common Business-Oriented Language, is the most widely used computer language in history. Of the 300 billion lines of code written by the year 2000, 80 percent was in COBOL. It is still widely used and supports a large number of government systems, such as vehicle records and unemployment insurance; On any given day, it could handle something worth $3 trillion in financial transactions. I think COBOL is a kind of digital asbestos, which was almost everywhere at one point, and is now dangerously difficult to remove.

COBOL was first proposed in 1959 by a committee including most of the US computer industry (including Grace Hopper). She called for a “common working language specification for automated digital computers” to solve a growing problem: the cost of programming. Software was written specifically for specific hardware, and if you wanted to run it on something else, it meant an almost complete rewrite. The committee contacted the Ministry of Defense, which gladly adopted the project.

The design of the COBOL language sets it apart from other languages ​​then and now. It was meant to be written in plain English so that anyone, even non-programmers, could use it; Symbolic mathematical notation was added only after much controversy. Most versions of the COBOL language allow hundreds of words (Java allows only 68), including “is,” “then,” and “to” for ease of typing. Some even said that COBOL was intended to replace computer programmers, who in the 1960s occupied a rare place in many companies. They were masters of technology that most people could barely understand. COBOL’s designers also hoped to create its own documentation, which would save developers time and make it easy. To maintain it in the long term.

But what does it even mean for it to be readable? Programs are not books or articles; They are conditional sets of instructions. While COBOL was able to transform the complexity of a single line of code into something anyone could understand, this distinction broke down in programs that were thousands of lines long. (It’s like an Ikea assembly manual: any given step is easy, but somehow it’s still incomplete.) Furthermore, COBOL was implemented with a piece of logic that had become despised: the GO TO statement, an unconditional branching mechanism that sends you from one section of the program to another. The result was “spaghetti code,” as developers like to say, that made self-documentation irrelevant.

Many computer scientists have had problems with COBOL from the beginning. Edsger Dijkstra famously disliked it, saying: “The use of COBOL paralyzes the mind; therefore, its teaching should be considered a criminal offence.” Likewise, Dijkstra disliked the GO TO statement, arguing that it made programs nearly impossible to understand. There was a degree of real snobbery: COBOL was often looked down upon as a purely utilitarian language intended to solve boring problems.

Jan Samet, one of the original designers, saw it differently—the language simply had the complex task of representing complex things, like Social Security. Or as another advocate wrote: “Unfortunately, too much business application software is written by programmers who have never had the benefit of teaching COBOL well.” Good COBOL was already self-documenting, but a lot depended on the specific programmer. Fred Grunberger, a mathematician at the RAND Corporation, put it this way: “COBOL, in the hands of a teacher, is a beautiful tool—an extremely powerful tool. COBOL, since it would be handled by a low-grade writer somewhere, would be a miserable mess.”