One reason I’ve seen for past efforts like this to fail is that COBOL uses fixed-point decimals instead of floating point. As a result, the decimal math functions are largely integer based and blazingly fast without losing precision.
When we translate COBOL to modern languages though, we end up either needing to use floats (which famously lose precision) or reimplement fixed point math in the new language, which often ends up significantly slower than the COBOL code. And when you’re streaming millions of financial transactions/sec you really need both.
I’m hopeful that somebody will crack that nut and free the finance sector from the 1970’s… But there’s more than just the usual challenges of a major rewrite.
If you target the same hardware in the end, why wouldn’t it be possible to have another language implement the same arithmetics with the same performance? I’m sure modern languages’ metaprogramming could enable that with a syntax that even sucks less…
Well, partially because in some cases it isn’t the same hardware! There are mainframe machines built to run COBOL programs efficiently, like IBMs Z Machines. In those scenarios, you’d likely have something like a standard Linux server as your API front-end forwarding requests to the COBOL machine.
And what makes them differ? Well, the CPU has dedicated instructions for certain fixed point operations. For a given request it’s only going to be a few ns faster, but when the vast majority of your workload is performing those actions, it adds up quick.
Another issue is rounding error. With Fixed Point numbers, you still have to round off partial results and the rules for rounding are surprisingly complex. So when you port from COBOL to Java, you need to ensure you port the rounding rules too, or you’ll get different results when you rerun last month’s reports. No bueno.
Anyway, all this is not to say that COBOL is better or worse than any other language, just that its primitives differ in behavior from other languages in important ways that can make it hard to migrate.
One reason I’ve seen for past efforts like this to fail is that COBOL uses fixed-point decimals instead of floating point. As a result, the decimal math functions are largely integer based and blazingly fast without losing precision.
When we translate COBOL to modern languages though, we end up either needing to use floats (which famously lose precision) or reimplement fixed point math in the new language, which often ends up significantly slower than the COBOL code. And when you’re streaming millions of financial transactions/sec you really need both.
I’m hopeful that somebody will crack that nut and free the finance sector from the 1970’s… But there’s more than just the usual challenges of a major rewrite.
If you target the same hardware in the end, why wouldn’t it be possible to have another language implement the same arithmetics with the same performance? I’m sure modern languages’ metaprogramming could enable that with a syntax that even sucks less…
Well, partially because in some cases it isn’t the same hardware! There are mainframe machines built to run COBOL programs efficiently, like IBMs Z Machines. In those scenarios, you’d likely have something like a standard Linux server as your API front-end forwarding requests to the COBOL machine.
And what makes them differ? Well, the CPU has dedicated instructions for certain fixed point operations. For a given request it’s only going to be a few ns faster, but when the vast majority of your workload is performing those actions, it adds up quick.
Another issue is rounding error. With Fixed Point numbers, you still have to round off partial results and the rules for rounding are surprisingly complex. So when you port from COBOL to Java, you need to ensure you port the rounding rules too, or you’ll get different results when you rerun last month’s reports. No bueno.
Anyway, all this is not to say that COBOL is better or worse than any other language, just that its primitives differ in behavior from other languages in important ways that can make it hard to migrate.