[Borborygymus]

In the late 90s I worked for a vendor of CRM software. A fair bit of billing and payment-handling code was written in COBOL. Wasn't mainframe - ran on a couple of flavours of proprietary Unix. The COBOL compiler vendor was Microfocus.

I didn't have any training in COBOL, but found it pretty easy to read and understand - at least for the fairly simple business logic in a billing system. I didn#t have to write anything - just do some debugging when it didn't output as expected. Wouldn't want to do anything too mathsy or heavy string processing with it, but it seemed a good fit for the application.

I did some more work for the same company later. A descendent of that software is still running today. At some point between 2000 and the late 20-teens they migrated to Linux, and I think at that point used some sort of COBOL-to-C transliteration software, and the Microfocus compiler was jettisoned. Not sure if the decision was because Microfocus was very expensive (I have heard that, but have no personal experience of it), or just didn't support Linux at that time.

That transliterated code is still running today, but a bit of a nightmare to maintain. If GNU Cobol has been mature enough whenever that migration happened, I suspect it would have been a much better approach than transliteration. Too late for that code base though.

[chasil]

The "mathsy" situation can be more difficult than most think.

GNU COBOL uses GNU MP by default for calculations, instead of IEEE-754, which came decades later.

Not understanding the math of COBOL has led to many failed porting attempts.

https://medium.com/the-technical-archaeologist/is-cobol-hold...

[vesinisa]

I hate that it's spam-walled but that Medium article sure was a riveting read.

Basically the conclusion is that for mainframe systems that need to process lots of transactions fast the performance of COBOL is hard to beat. Languages like Java are not even very well suited for these type of calculations since BigDecimal is not part of the core programming idiom.

With the additional cost that migration would carry, it's actually less risky and more cost effective to keep maintaining the COBOL system, even if it means paying in-house to train programmers in this ancient technology.

[guenthert]

"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."

Would it have killed her to tell, how COBOL does the math? I would think that for financial transactions fixed precision arithmetic is used, so IEEE-754 compatibility is irrelevant.