cobol

Cobol is in the news again. Last time COBOL was in the news it was 2020, and my home state of New Jersey desperately needed COBOL programmers to maintain their unemployment system. Now, COBOL is in the news because its the language the government's most sensitive systems are written in, and reporters are convinced that the broccoli-haired brownshirts of DOGE won't know how to do anything with it.

On Odd Lots, Joe Wisenthal semi-seriously asked Nathan Tankus if they could just "put COBOL into ChatGPT and convert it to Python". Nathan responded that a migration would be difficult, because COBOL is so low-level that it literally depends on the hardware its written on. ("Even with the modernizations, you know, modernizing these systems mean changing the physical architecture that they run on and maybe updating the language so that it can also be used on say, a computer and not just a mainframe.")

Interesting. I won't say more about the DOGE kids, who are obviously some of the most nakedly wealth-seeking and careerist specimens the Bay Area has produced to date, except to say that they seem to lack to humility, patience, and curiosity to work with a system like the ones written in COBOL at the Treasury Department. Their main barrier in my mind is dispositional, not technical¹.

But technically. It's actually unfathomable to my Python-slop, Docker-container-ified brain that a programming language could be irreplaceablely tied to some hardware. The Common Business Oriented Language looks like assembly, so maybe it comes close? A hello world:

IDENTIFICATION DIVISION.
PROGRAM-ID. IDSAMPLE.
ENVIRONMENT DIVISION.
PROCEDURE DIVISION.
    DISPLAY 'HELLO WORLD'.
    STOP RUN.

When I was reading about Cobol, people were making a lot of fuss about the columns. Each keyword (eg. PROCEDURE DIVISION) needs to be in the same precise column of the other keywords, and all the sub instructions (eg. DISPLAY) need to be in the next column. The idea of reserved keywords is reminiscent of SQL, and I felt that the columns were approximately the same as Python's reliance on indentation. COBOL is older, though so the backstory is cooler: COBOL needs columns because that's how the punchcards were arranged.

There are also some properties of COBOL as a programming language that make it really well suited to batch data processing type tasks that I assume institutions like the Treasury Department need to do. First, COBOL uses a decimal representation of numbers (not the binary representation common to FLOPs today) so programs avoid rounding errors². Second, COBOL is like, relatively readable. Readable relative to the other programming languages in circulation at the time, I guess — no offense to Grace Hopper. All the variables are global, and lack of structured programming in the early years means that control flow can be a bit of a mess, but for the most part I think intentions are clear³. Third, COBOL requires variables to be statically typed. Another W for static types. So yes, COBOL has a few properties that make it well-suited to the tasks it performs (certainly better suited than the alternatives of the 70s and 80s).

Still, though, nothing about this presents a purely technical limitation that makes COBOL irreplaceably tied to some particular hardware architecture. I can compile that hello_world.cbl into a binary that can run on my laptop, thanks to the hard work of the folks at gnuCOBOL. Compiled binaries need to be translated into machine code (usually X86 or RISC-V) to be run on a server, but it would be useless decision to change from servers that run x86 to RISC-V, and anything that can run RISC-V can run anything RISC-V. That makes what Nathan says on Odd Lots still a bit incorrect. No language, as far as I know, is so low-level as to lack any portability.

I’m coming back to the idea of dispositional problems (which is maybe what Nathan means when he talks about "business logic"). The odds that even an above-average, thorough programmer could migrate a system like this without having serious ramifications is vanishingly small.