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: 5, Insightful) by DannyB on Monday September 16 2019, @02:36PM (10 children)
Back in my college daze. I was still using BASIC. Rebelling against FORTRAN. Saw no possible use for COBOL. I had a side (work study) job in the computer center actually writing code. Was friends with the head of the computer center who was seriously into COBOL.
He told me that COBOL would be around at the turn of the century. (We didn't call it turn of millennium back then, but ah, hindsight...) I couldn't believe him. Just could not. But he explained why he believed this. The sheer economic value of COBOL code that existed, even in 1980, was so vast that it could never be replaced in only twenty years. Too many systems deeply depended on COBOL.
Of course, I was still a youngster and he had a few more years of wisdom. Of course, he was right.
I see the same thing now in Java. And for the same reason. Too much Java code exists to be replaced any time soon. And especially in very large, very conservative organizations. Including especially banks and financial institutions. Places where you don't have hipsters coming up with new framework of the week that everything must be rewritten in . . . just because. Java has been extremely conservative about backward source and binary compatibility. Really old source and binaries will run on current runtimes -- and that's hard to do, just ask Python.
Why COBOL? I didn't see it for a long time. But eventually did. As I looked back on computer history, I came to realize (which I also partly realized in college) that mainframes are seriously RECORD oriented machines. Perfect for business. Where UNIX like systems, or even microcomputer OSes that give you byte-oriented file read-write are more desirable for all kinds of uses, including records. COBOL is highly record oriented. And text oriented. PICTURE this, that you can read in a card, and specify the character positions of various fields, and their parsing formats and have them loaded into variables on each iteration. All files are "stacks of punched cards". Even modern files, are text, with each 80 column line is a record. Or wider records now that we're not worried about backward compatibility to punched cards. But a 1980 COBOL program will just work. So while I now understand WHY the language is attractive, and what niche it serves, and I understand the economic reasons it is still around . . .
I would never want to use COBOL myself. Just as some would never want to use Java. Or other languages. Hey if it's not for your problem domain, don't use it. But don't knock it if it is in widespread use. There is probably a reason for that. Warts and all.
To transfer files: right-click on file, pick Copy. Unplug mouse, plug mouse into other computer. Right-click, paste.
(Score: 0) by Anonymous Coward on Monday September 16 2019, @02:55PM
Finally some one gets it!!!
COBOL
RPG (assembler in drag)
IBM ASM
ALL are powerful languages for bulk processing ng. All from the day that 1400 machines were running the world. COBOL was the “first” write once and run on anything. RPG was a direct replacement of 1403 back-a-lack boards and 4k core that ran the I/O cycle and set flags IBM ASM move 16kB in a single “click” tick.
ACH transfers are card decks. Amounts are not 2.31e+10. Real processing take really machines. IBM understood business. The rest are Sciences that make data gathering devices.
Kids today?
(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!
To transfer files: right-click on file, pick Copy. Unplug mouse, plug mouse into other computer. Right-click, paste.
(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.
(Score: 2) by Thexalon on Monday September 16 2019, @05:14PM (1 child)
Counterpoint: Sometimes the platform the thing needs to run on forces you to use a particular language no matter how much it sucks. For example, web browsers only universally understand Javascript, so web developers code Javascript not because they want to but because it's the only choice available. Or writing an application in a machine's machine code because there aren't any compilers / interpreters yet for that CPU and somebody demanded that you write software for it, not because it's a great language.
The only thing that stops a bad guy with a compiler is a good guy with a compiler.
(Score: 2) by DannyB on Monday September 16 2019, @06:46PM
In the 70's it was obvious that some machines were 'biased' towards certain languages. Or modes of thinking.
Developers, like today, or all humans actually, take the path of least resistance.
To transfer files: right-click on file, pick Copy. Unplug mouse, plug mouse into other computer. Right-click, paste.
(Score: 0) by Anonymous Coward on Monday September 16 2019, @07:40PM (2 children)
The *machines* were not record oriented. The *language* was record oriented. The machines only seem record oriented because they are viewed through the prison of an incredibly limited language. (I originally wrote prism, but it autocorrected and as so often happens, the new word is better).
Lots of business processes seem to be record oriented... Right up until something happens that doesn't fit in the record. In the 50s it was normal for humans to write little notes in the margins or whatever... Computers cannot do this. Limitations in the language directly cause limitations in the process. Why do you suppose the IRS, the phone company and so many other COBOL users are so notoriously inflexible? They can only do what the computer lets them do.
COBOL is one of the best examples of "the worst thing that can possibly work." That is not a strength. Inability to get rid of it doesn't make it good.
(Score: 2) by Muad'Dave on Tuesday September 17 2019, @04:34PM (1 child)
> The *machines* were not record oriented.
Early filesystems, at least those on the Interdata/Perkin Elmer/Concurrent machines I used to work on, were record-oriented. You could declare a file as 'indexed' with a fixed max record length like 80 or 132 characters, or as 'contiguous' where the record length was fixed at 256 bytes (one blocksize - used for executables, etc). There was no concept of a line terminator.
Obviously the disk drive itself was just storing 256 byte blocks.
(Score: 0) by Anonymous Coward on Wednesday September 18 2019, @04:28AM
Huh. Interesting. So this was effectively an abstraction over the physical blocks, to have OS-level controllable virtual blocksize? Ie. there was no recordsize-centric design at the hardware level?
(Score: 0) by Anonymous Coward on Monday September 16 2019, @10:35PM
Most COBOL code stick because of regulations. That data you have? By law must match what it did last year. So you re-wrote it. Does it match? *reaaaaallly* match. I mean all several trillion records you have. Does it match? Does it roll up the same? OR leave it the fuck alone and the regulators are fine. No fines. Java will stick for the same reasons. Oracle smells the blood in the water :)