https://medium.com/@bellmar/is-cobol-holding-you-hostage-with-math-5498c0eb428b
Face it: nobody likes fractions, not even computers.
When we talk about COBOL the first question on everyone's mind is always Why are we still using it in so many critical places? Banks are still running COBOL, close to 7% of the GDP is dependent on COBOL in the form of payments from the Centers for Medicare & Medicaid Services, The IRS famously still uses COBOL, airlines still use COBOL (Adam Fletcher dropped my favorite fun fact on this topic in his Systems We Love talk: the reservation number on your ticket used to be just a pointer), lots of critical infrastructure both in the private and public sector still runs on COBOL.
Why?
The traditional answer is deeply cynical. Organizations are lazy, incompetent, stupid. They are cheap: unwilling to invest the money needed upfront to rewrite the whole system in something modern. Overall we assume that the reason so much of civil society runs on COBOL is a combination of inertia and shortsightedness. And certainly there is a little truth there. Rewriting a mass of spaghetti code is no small task. It is expensive. It is difficult. And if the existing software seems to be working fine there might be little incentive to invest in the project.
But back when I was working with the IRS the old COBOL developers used to tell me: "We tried to rewrite the code in Java and Java couldn't do the calculations right."
[Ed note: The referenced article is extremely readable and clearly explains the differences between floating-point and fixed-point math, as well as providing an example and explanation that clearly shows the tradeoffs.]
(Score: 3, Insightful) by bussdriver on Monday September 16 2019, @03:55PM (2 children)
If it ain't broke don't fix it!!! That needs to be tattooed onto every nerd's hands.
If you can't manage the COBOL, then get out of the career; you are not competent enough. Bind to new languages if you must. The insanity and utter failure of software is that we are rewriting everything constantly when the real problems are BUGS. It takes decades of man hours to perfect something and even then the astronomical level of branching involved can (and is) hiding unnoticed bugs. An experienced wise old programmer will tell you that whatever new design you invent it'll have pitfalls to it and those will grow with time (and other people's opinions.) Now some things will become obsolete like the horse and buggy... so starting over might actually make sense; but to re-invent the wheel is foolishness (no, adding rubber to a wheel shouldn't be reinvention.)
The older the code, the more it's been tested and debugged, the more valuable it is. You do not redo it unless absolutely necessary. The goal of next gen programming needs to be write-once software that will last (or at least components of it) forever and be efficient to produce. COBOL might be a pain in the ass but it clearly succeeded in filtering out moron programmers (unlike Java) and it is lasting forever. Rust maybe could be another COBOL/C... it's goal is efficient long-term write-once... but again, only for new code; secure mature C / COBOL does not need rewriting.... because the work that Rust helps with was done the hard way already. Tweaking old code to fit new needs or removing bugs from it is just fine. It's unlikely you will ever save $$$ porting it unless you have perfect translation software.... and the support costs of shifting are justified by the gains of the new tools.
People talking of porting COBOL are like a carpenter replacing an old nailgun with a bluetooth enabled hammer! A specialty tool used in it's niche will probably beat a hip new generic tool.
(Score: 5, Funny) by DannyB on Monday September 16 2019, @04:29PM
Hipsters: If it ain't broke, fix it 'till it is!
Young people won't believe you if you say you used to get Netflix by US Postal Mail.
(Score: 1, Informative) by Anonymous Coward on Monday September 16 2019, @06:06PM
It has no way not to be; if it were written like today, the olden days' hardware would be totally unable to run it at all.