I've read about this COBOL argument.

I'm not an expert, so I might be wrong on the details.

The deal is that COBOL has native fixed point math. Floating point just doesn't work. So, .1 just not exist at all in floating point. See: https://www.exploringbinary.com/why-0-point-1-does-not-exist...

Some have said that Java and other languages have libraries that can do fixed point math calculations. Yes, that is true. Java also does all it's fixed point math via library calls, which are much slower than native opcode support. And while it is fine for millions of transactions or hundreds of millions, when you are doing 2 billion or more transactions per second, like what happens in our financial systems, these external libraries just are not fast enough.

The dilemma with migrating COBOL is not that you are migrating from one language to another, but that you are migrating from one paradigm to another. The edges of Java or python on Linux have a different shape than the edges of COBOL on a mainframe. In some cases COBOL may have allowed the application to extend past what modern languages can support. For those cases COBOL running on a modern mainframe will actually be the cheaper, more performant and more accurate solution.

Also, COBOL works on machines that can hotswap any piece of hardware, and degrade gracefully if a processor dies. Reliability is everything when working with billions of dollars. Those machines also support ridiculously large I/O speeds; if you can't handle a day's worth of transactions in real time, you're out of business.

Plus, how would you even update these kind of systems? They are running trillions of transactions per day. They are using very complex code. Take the insurance industry, for example. They have 50 states, each with different legal requirements for insurance, that change all the time, and by all the time, I mean daily, not yearly. So you have 40 or 50 years of code base, and most of it commented out or maybe just not called as a function anymore but still exists. So if you write brand new code, and you have a Fortune 100 insurance company that sends out billions of dollars in claims and investments daily, pays out life insurance, pays out money for accidents, workers comp, homeowners insurance, umbrella insurance, etc, and it is working great right now, if you are the CEO, are you going to convert your working system over to Java or c or whatever?

And, there is just no way to test any system that replaces current COBOL programs, let alone the entire system, with all the different kinds of computers, technologies, etc, because it is not just the COBOL. It's the entire system. Just no way. Nobody knows what’s hooked up to what in these server rooms. It would take Indiana Jones with a torch to explore the damn things without setting off the booby traps.

And, actually, I read about one insurance company that looked into it, and hired IBM to do a feasibility study and if it was feasible, that they should do it. So IBM did the study, and despite the literally hundreds of millions of dollars they would clear to convert, they just said "F-ck it" and walked away. Who wants to take on that kind of liability if it doesn't work? Who wants to risk their company's reputation on something like that? Where all of a sudden, 85-year-old women are not getting their monthly annuity check and you have tens of thousands of them being kicked out of their homes because they are not getting their monthly annuity to pay their mortgage. What a nightmare.

Rewriting all the COBOL code in another language, just to have a snazzier language, is super costly, extremely risky, and zero benefits. Using another programming language, just for the sake of using the other programming language is a complete waste of time and effort. Stockholders, CEOs, managers, hate big projects that offer no benefit.

Examples:

“I just got through a conversion to go from COBOL to Java,” Hinshaw said. “It’s taken them four years, and they’re still not done.”

The Commonwealth Bank of Australia replaced its core COBOL platform in 2012, it took five years at a final cost of $749.9 million ($1 billion Australian).

TSB, a UK bank, changed from a COBOL-based system in 2018 because of a buyout. The bank was unable to trade for days. The migration cost was $454 million. Engineering the actual migration was even more. TSB lost $68 million from financial fraud while its systems were melting down. Customer compensation for the systems being down was more than $172 million. The bank spent $168 million on new staff to deal with 204,000 customer complaints. The CEO resigned. TSB is still trying to fix the damage.

It's very easy to tell someone else to switch languages when it's not your ass on the line. But if it IS your ass, there's a whole other look to it.

As far as getting new programmers - that is no problem. COBOL is very easy to learn. It is very easy to train people up. And what programmer doesn't know more than one language anyways? It's just one more language.