Good article, very informative. You used to hear the "can't do the math" excuse a lot around y2k with respect to migrating these systems to something (anything?) else. You don't hear as much nowadays. I think a lot of that boiled down to properly handling rounding, which is non trivial as other posters have mentioned.
A lot of commenters here are missing the point about decimal library support. The point is not that language x does or doesn't have some sort of support for decimal math, the point is it's not native support. Even if language x supports a decimal type, back by a byte[] (for example) there is still function/method call overhead for basic operations (+-/*). For high volume stuff she's talking about, it adds up, fast.
I think there are a few languges with similar native decimal support; ada and pl/1 iirc.
Cobol is an albatross that's going to be with us for a loooong time to come.
>there is still function/method call overhead for basic operations (+-/*). For high volume stuff she's talking about, it adds up, fast.
With the right style of C++ programming (trait/templated focused instead of inheritance) or Rust's static-dispatch-by-default it should be no more of a performance impact than 'native' Cobol calls after the compiler optimizes it.
A lot of commenters here are missing the point about decimal library support. The point is not that language x does or doesn't have some sort of support for decimal math, the point is it's not native support. Even if language x supports a decimal type, back by a byte[] (for example) there is still function/method call overhead for basic operations (+-/*). For high volume stuff she's talking about, it adds up, fast.
I think there are a few languges with similar native decimal support; ada and pl/1 iirc.
Cobol is an albatross that's going to be with us for a loooong time to come.