64
this post was submitted on 23 Aug 2023
64 points (92.1% liked)
Programming
17313 readers
208 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities [email protected]
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
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.