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.

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

> 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

Java does math the same way as COBOL does math, if you use java.math.BigInteger, java.math.BigDecimal, javax.money, etc

Unlike (say) C++ or C#, Java doesn't have operator overloading, so BigInteger/BigDecimal/etc don't let you use ordinary operators such as + or *, instead you have to use method calls such as add() and multiply()

But, that's not really that verbose compared to Cobol's "ADD ONE TO X GIVING X", etc.

And if you really want + and * with BigInteger/BigDecimal/etc, you can use a JVM language which has operator overloading, such as Kotlin or Java

I like decimal math, and I don't think it's well supported in many languages.

I also like AppleScript's crazy English (or French or Japanese) syntax, and I can't help but wonder if it (and HyperTalk) were partially inspired by COBOL.