Archive link. I went down the rabbit hole a bit and came back with this old but extremely salient article on why COBOL is still deeply embedded in government, banking, and aviation systems, and...
I went down the rabbit hole a bit and came back with this old but extremely salient article on why COBOL is still deeply embedded in government, banking, and aviation systems, and why it's difficult to replace. Floating point arithmetic (the default for modern programming languages) is not "good enough for government work"!
From the article:
When we talk about COBOL the first question on everyone’s mind is always Why are we still using it in so many critical places? Banks are still running COBOL, close to 7% of the GDP is dependent on COBOL in the form of payments from the Centers for Medicare & Medicaid Services, The IRS famously still uses COBOL, airlines still use COBOL (Adam Fletcher dropped my favorite fun fact on this topic in his Systems We Love talk: the reservation number on your ticket used to be just a pointer), lots of critical infrastructure both in the private and public sector still runs on COBOL.
Why?
The traditional answer is deeply cynical. Organizations are lazy, incompetent, stupid. They are cheap: unwilling to invest the money needed upfront to rewrite the whole system in something modern. Overall we assume that the reason so much of civil society runs on COBOL is a combination of inertia and shortsightedness. And certainly there is a little truth there. Rewriting a mass of spaghetti code is no small task. It is expensive. It is difficult. And if the existing software seems to be working fine there might be little incentive to invest in the project.
But back when I was working with the IRS the old COBOL developers used to tell me: “We tried to rewrite the code in Java and Java couldn’t do the calculations right.”
This was a very strange concept to me. So much so that a panicked thought popped immediately into my head: “my God the IRS has been rounding up everyone’s tax bill for 50 years!!!” I simply could not believe that COBOL could beat Java at the type of math the IRS needed. After all, they weren’t launching men into space over at New Carrollton.
One of the fun side effects of my summer learning COBOL is that I’m beginning to understand that it’s not that Java can’t do math correctly, it’s how Java does math correctly. And when you understand how Java does math and how COBOL does the same math, you begin to understand why it’s so difficult for many industries to move away from their legacy.
... COBOL is a compiled language with stack allocation, pointers, unions with no run-time cost of conversion between types, and no run-time dispatching or type inference. Java, on the other hand, runs on a virtual machine, has heap allocation, does not have unions, incurs overhead when converting between types, and uses dynamic dispatching and run-time type inferencing. While it is possible to minimize the amount that these features are used, that usually comes at the cost of having code that is not very “Java like”. A common complaint with translators is that the resulting Java code is unreadable and unmaintainable, which defeats much of the purpose of the migration. Performance of Java Code Translated from COBOL, UniqueSoft
Lest you dismiss this issue with “Oh yes, but that’s Java and Java sucks too” remember this: most modern day programming languages do not have support for fixed point or decimal built in either. (Actually I think the correct statement is NONE of them do, but I couldn’t confidently verify that) You can pick a different language with a different combination of trade-offs, sure, but if you need the accuracy of fixed point and you think that the tiny performance cost of importing a library to do it might pile up you really only have one option and that’s COBOL.
Rust wasn't around when this article was written, but does have a fixed point crate. Any Rust developers care to comment on the potential efficiencies compared to Java?
I've been involved in a banking modernization project and there's nothing really special about COBOL except for years of momentum. There's some hardware shortcuts that specialized mainframes can...
I've been involved in a banking modernization project and there's nothing really special about COBOL except for years of momentum. There's some hardware shortcuts that specialized mainframes can offer but embarrassingly parallel commodity hardware can easily outperform any realistic batch-processing problem dollar-for-dollar.
But also there is no substantial "problem" with using an industry-adopted language (eg. COBOL or Ada) over something more popular across industries. These programmers have years of industry experience and are often quite good at knowing the value that they bring to the table. Management wants flexibility and interchangeable humans to drive the cost of labor down. But the entrenched systems are winning. COBOL is going to stay around for a few more decades at least.
Banks have spent probably double the amount in savings that they could have had if any of the modernization projects over the years were ever successful--most fail. They are usually just trading one locked-in vendor for another more modern but less customized system.
The overall point about fixed vs floating point arithmetic is a very good one (and one that I absolutely do not trust Elon’s asset stripping crew to account for), although I don’t buy this...
The overall point about fixed vs floating point arithmetic is a very good one (and one that I absolutely do not trust Elon’s asset stripping crew to account for), although I don’t buy this reasoning specifically:
if you need the accuracy of fixed point and you think that the tiny performance cost of importing a library to do it might pile up you really only have one option and that’s COBOL
It’s like saying you can’t move house because none of the new houses have the curtains you like in the kitchen. It’s true, they don’t have the curtains already, but you probably shouldn’t be making your whole decision about where to live based on the 20 minutes it’d take to fit them.
You might well not want to move house because of all the million other risks and uncertainties and costs and efforts it involves - and that would totally make sense, whether we’re talking about houses or battle tested codebases - but “this one thing has to be an existing feature, adding it yourself isn’t acceptable” seems a bit of an odd one to focus on.
[Edit] Also, if your house has a thatched roof that nobody knows how to properly maintain anymore, you’ll eventually hit a point that you decide to move despite all those uncertainties, even if it’s been fine for however long before that. Either because you see the balance of risks shifting and want to get ahead of it, or because the roof starts leaking and you want to get out, or because the roof catches fire and you no longer have a choice…
most modern day programming languages do not have support for fixed point or decimal built in either. (Actually I think the correct statement is NONE of them do, but I couldn’t confidently verify that)
Java has a BigDecimal class. But since it doesn't have operator overloading, the code using it will look pretty ugly. But you wouldn't normally use this directly. It's common practice in most...
Java has a BigDecimal class. But since it doesn't have operator overloading, the code using it will look pretty ugly.
But you wouldn't normally use this directly. It's common practice in most languages to have some kind of custom Money type that specifically represents an amount of money. It should have methods implementing whatever operations you need with correct rounding.
For this sort of port, there would need to be a Money type that has operations that work exactly like COBOL.
My day job is maintaining, developing and deploying a large scale financial management system, the core of which is an in house 4GL (self hosted, the 4GL is written in itself) which ends up being...
My day job is maintaining, developing and deploying a large scale financial management system, the core of which is an in house 4GL (self hosted, the 4GL is written in itself) which ends up being COBOL. I started work on this in the early 90s, and I'm still working on it to this day.
I like the language quite honestly. Last I counted the codebase was in the order of 50 million LOC.
Archive link.
I went down the rabbit hole a bit and came back with this old but extremely salient article on why COBOL is still deeply embedded in government, banking, and aviation systems, and why it's difficult to replace. Floating point arithmetic (the default for modern programming languages) is not "good enough for government work"!
From the article:
Rust wasn't around when this article was written, but does have a fixed point crate. Any Rust developers care to comment on the potential efficiencies compared to Java?
I've been involved in a banking modernization project and there's nothing really special about COBOL except for years of momentum. There's some hardware shortcuts that specialized mainframes can offer but embarrassingly parallel commodity hardware can easily outperform any realistic batch-processing problem dollar-for-dollar.
But also there is no substantial "problem" with using an industry-adopted language (eg. COBOL or Ada) over something more popular across industries. These programmers have years of industry experience and are often quite good at knowing the value that they bring to the table. Management wants flexibility and interchangeable humans to drive the cost of labor down. But the entrenched systems are winning. COBOL is going to stay around for a few more decades at least.
Banks have spent probably double the amount in savings that they could have had if any of the modernization projects over the years were ever successful--most fail. They are usually just trading one locked-in vendor for another more modern but less customized system.
The overall point about fixed vs floating point arithmetic is a very good one (and one that I absolutely do not trust Elon’s asset stripping crew to account for), although I don’t buy this reasoning specifically:
It’s like saying you can’t move house because none of the new houses have the curtains you like in the kitchen. It’s true, they don’t have the curtains already, but you probably shouldn’t be making your whole decision about where to live based on the 20 minutes it’d take to fit them.
You might well not want to move house because of all the million other risks and uncertainties and costs and efforts it involves - and that would totally make sense, whether we’re talking about houses or battle tested codebases - but “this one thing has to be an existing feature, adding it yourself isn’t acceptable” seems a bit of an odd one to focus on.
[Edit] Also, if your house has a thatched roof that nobody knows how to properly maintain anymore, you’ll eventually hit a point that you decide to move despite all those uncertainties, even if it’s been fine for however long before that. Either because you see the balance of risks shifting and want to get ahead of it, or because the roof starts leaking and you want to get out, or because the roof catches fire and you no longer have a choice…
I'm pretty sure that Haskell and Scala qualify.
Java has a BigDecimal class. But since it doesn't have operator overloading, the code using it will look pretty ugly.
But you wouldn't normally use this directly. It's common practice in most languages to have some kind of custom Money type that specifically represents an amount of money. It should have methods implementing whatever operations you need with correct rounding.
For this sort of port, there would need to be a Money type that has operations that work exactly like COBOL.
My day job is maintaining, developing and deploying a large scale financial management system, the core of which is an in house 4GL (self hosted, the 4GL is written in itself) which ends up being COBOL. I started work on this in the early 90s, and I'm still working on it to this day.
I like the language quite honestly. Last I counted the codebase was in the order of 50 million LOC.