There's been a lot of talk about how many states' unemployment systems are written in a 60-year-old programming language, COBOL. It raised a lot of emotions and commentary, for sure, but hardly the right ones, in my opinion.
Thread. 1/
Thread. 1/
The core of the operating system you're writing this on is pretty much certainly written in C. That programming language is 48 years old. Most of them, with the notable exception of Windows, are built upon a standardized system architecture that's about just as old. 2/
If COBOL is obsolete, then so are C and POSIX. But all of those have been maintained and improved upon over the years. The latest issue of the COBOL standard was in 2014. (2018 for C and POSIX). 3/
Why does C feel somewhat less obsolete than COBOL? I doubt it's their 12-year age difference when they're both so old. It's probably exposure, and perhaps in a related way, popularity. 4/
COBOL never really caught on in the microcomputer market. It never really got used in consumer devices and front-end systems. Hobbyists and small-time developers were never really exposed to it. Not in the 1980s, not now. C, however, definitely did catch on. 5/
However, COBOL has always been absolutely widespread on mainframe and other enterprise systems, to this day. It's not just unemployment systems. It's every major bank, credit company, insurer, plenty of major retail chains, manufacturing giants, and others. 6/
It's estimated that 80 to 85% of all credit card transactions worldwide are processed by a mainframe computer, and likely a business logic system written in COBOL 7/
And much like there isn't a realistic scenario for replacing your OS kernel by a new one written in a more modern systems language like Rust in the near future, there is even less of a path for migrating mission-critical business systems to new code in a more modern language. 8/
The fact that government business logic (and plenty of other private-sector stuff as well!) is still powered by old COBOL code running on monolithic infrastructure isn't neglect. It's risk management. The cost to migrate mission-critical systems is far from just financial. 9/
No matter how much communication and testing you do, you'd be pitting brand new code against decades-old, time-tested, many-times-fixed and proven code running complex logic. You'd be spending years just running in parallel trying to locate and fix bugs. 10/
And when it's finally time for that fancy new code to lose the training wheels and go live, you'd still run the risk of grinding your business to a halt, or piss off stakeholders and clients, because you only have so much time to complete the project. 11/
Which executive, which project manager would be willing to put their head on the stake and undertake that migration project? Especially in a large corporation or in government? Especially while that old system just, you know... works? 12/
In the end, it's just a programming language. It's a tool. In a toolchain that's still maintained and updated, used to make programs that are running on an infrastructure which is hopefully maintained and kept updated as well. 13/
Because that's the other thing. Those articles I've been reading are sometimes illustrated with pictures of absolutely ancient computers like an IBM 1401 (one of the earlier machines that had a COBOL compiler). Or maybe more recent DEC minis from the 1970s. 14/
But that's hardly the reality. Mainframes are still being made, and the OSes they run are still maintained and improved. (Or you can just stick Linux on them if you want.) And they're basically supercomputers-in-a-cabinet at this point. 15/
Take the IBM z15, which launched last year. 64 bits, up to 190 cores at 5 GHz, terabytes of RAM, and plenty of goodies that would put a PC server rack to shame. (Pic: @a_giorgio, CC BY-SA via @WikiCommons ) 16/ 
Its main operating system, called z/OS as of 2000 (though other options exist, including Linux), is of course still under active development, and the latest release was last September (V2R4). There's nothing antiquated in any of that. 17/
Unless you consider backwards compatibility to be antiquated. Because I think it's source- *and* binary-compatible going back to the 1960s. A very important thing for enterprise, and one fewer reason to rewrite all that code. 18/
And with COBOL being an ISO standard, even if you switch environments, it's probably easier and safer to port your existing code than to replace it. 19/
So why not gradually replace modules with newer code as need arises? Eh, maybe. I know some companies that are doing that. But others decide that consistency is valuable, and as I said, COBOL isn't really fundamentally obsolete or broken. 20/
After all, mainframes do have C++ and Java environments. z/OS and iSeriesOS do, anyway. But interfacing between two languages is always kind of a pain, and sometimes error-prone. 21/
In my opinion, all that COBOL has really going against it is perhaps its old-school syntax, lack of modern features, and some type safety issues. But the last two factors also apply to C, and we're not actively getting rid of all C code. 22/
So why all the media commentary? Lack of familiarity. Lack of insight into how big business operates, which tends to be pretty opaque. But the fact that COBOL is 60 years old? Perhaps not so much. 23/
The last time I wrote COBOL was last December, as a solution to an #AdventOfCode problem (specifically Day 4, spoiler alert). The rationale for my choice of language can be inferred from the comment at the top of the file. github.com/DrFrankenstein… 24/
So, alright. Am I saying COBOL is a Very Useful™ language and that you should write your programs in it?
Ehh, no. Probably not. 25/
Ehh, no. Probably not. 25/
But should we toss those billions of lines of working mission-critical business logic and replace them with a language several generations newer like Java or Go? Definitely not. And that's my point. 26/
Should you learn COBOL? I'd say give it a try if you want. GnuCOBOL is free, works well, and uses GCC as its backend. It's only use in boring bureaucratic hell, but it pays well into 6 figures because of stable demand but low supply. 27/
What about mainframes? @mastermainframe's learning system gives you a crash course in z/OS and a shell profile. It's interesting to discover an OS so far removed from the usual UNIX and Windows stuff we're used to on PC. 28/
(aside: apparently, a new revision of that system just launched today.)
