SoylentNews is people
SoylentNews
from the COBOL-is-often-fractionally-better dept.
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: 2) by bussdriver on Monday September 16 2019, @04:07PM (4 children)
Software Engineering isn't the problem. It's HUMANS. Our inherent flaws and limitations are what has held back the evolution of software.
We can't specify complex systems in detail today much better than back then. Agile is kind of an admission that we can't handle complex software by planning. Sure you can use everything we have and the next 20 years of progress and you'll still end up with an edited specification that changes while it is being implemented and runs into design dead-ends requiring work around kludges, etc. It's like you need to implement a working 1.0 before you realize all the mistakes then design a rewrite that isn't as nearsighted... because hind-sight is so good and we never seem to foresee well enough... It may have less to do with human limitations and flaws/politics than it has to do with accurately predicting the future in a way that the ideal optimal path can be chosen (for a set of problems that are not yet completely understood.)
Think of English, well written things are revised and edited even by the best authors. Software is the same but it's far more intricate... Changing phrasing on 1 sentence doesn't alter the whole book so it fails to communicate it's meaning.
(Score: 1, Insightful) by Anonymous Coward on Monday September 16 2019, @04:42PM (2 children)
It's a good point, but one of the other areas that COBOL became relevant was a drive to reduce or eliminate programming jargon and instead approach processing using ordinary language tools. COBOL (and FORTRAN) were implementations trying to put the tools of programming in the hands of not programmers but subject-matter experts. When dealing with the complexity of a business or scientific problem, instead of requiring intermediary developers or developers who must master business or science concepts why not design the system such that end users can understand the concepts well enough to either program themselves or do some level of debugging on it? Placing programming in end-users hands these days resorts to, "learn the intricacies, syntax, and quirks of language ______." Not that COBOL and FORTRAN don't have these also, but there was intention to lessen that burden and allow the scientists and businesspeople of the days of the language development direct access to understanding a codebase. At the tradeoff of some degree of flexibility and elegance.
(Score: 2) by bussdriver on Monday September 16 2019, @05:13PM
Anybody can program. Not everybody can do it well. Something people forget; besides that, your IQ is like a power meter and no matter how big yours is, it goes down the harder you concentrate on tasks. A great programmer who sucks at some science is going to use up their IQ on the problem while an expert is going to use their IQ on the programming. It really depends upon the situation which one is going to do better. Complex languages like C++ that provide way too much bloat of options (or Perl with insane linguistic power) might entertain a pro programmer also lower their IQ thinking about the details. For systems work, those details ARE the work so it's not as horrible... but they work when the pro knows when to ignore all the feature bloat and work with the proper subset (and future Perl 6 gurus will make the language conform to the problem at hand and then use an even more niche subset. Will people notice the powerful potential? probably not...)
(Score: 0) by Anonymous Coward on Monday September 16 2019, @07:54PM
And SQL. But the notion of some non-technical business specialist writing their own queries in SQL would be laughable today. These languages all date from an era when it was commonly believed that the hard part of programming was the syntax. And it's not a surprise, many non-programmers today still think that. But that's as absurd as the notion that the hard part of being a lawyer is the Latin. We now know that not only is syntax not the hard part, but these languages are the opposite of helpful : it's important to keep code concise, and to make the language efficiently represent the problem. "English-syntax" languages make both of those things worse.
In hindsight, this is obvious. Natural languages are for talking to humans, and computers do not work like humans. But in the 1950s, nobody realized just how different they are.
Nobody blames Henry Ford for not including seat belts and power steering, but that doesn't mean there's any reason to drive a Model T today except for historical interest.
(Score: 2) by kazzie on Monday September 16 2019, @05:36PM
Are you writing that on behalf of Bot?