COBOL Will Outlive Us All 318
jfruh writes "Here's an old computer science joke: What's the difference between hardware and software? If you use hardware long enough, it breaks. If you use software long enough, it works. The truth behind that is the reason that so much decades-old COBOL code is out there still driving crucial applications at banks and other huge companies. Many attempts to replace COBOL applications flopped in the 1980s and '90s, and we're stuck with them for the foreseeable future — but the Baby Boomers who wrote all that code are now retiring en masse."
Comment removed (Score:3, Interesting)
If a technology is outdated, outsource it. (Score:5, Interesting)
The financial sector, the lumbering dinosaur that accepts change only when they have no other option, and the ones maintaining decades-old mainframes really have no incentive to change technologies at the moment. It's easier to just outsource the maintenance and servicing of the mainframes. There are enough of coders (like in the company I joined) in developing countries across the world who would gladly take it up.
From my experience, there is little development happening any more. I think the day when they run out of people who want to this crappy menial job (which is never) is the day COBOL will go extinct.
If it aint broke... (Score:5, Interesting)
COBOL was supposed to be a quick fix (Score:4, Interesting)
http://en.wikipedia.org/wiki/COBOL [wikipedia.org]
Speaking of COBOL outliving us all... (Score:5, Interesting)
Does anybody know what language(s) are used for the "Dead Hand" second-strike control system that the Russians were working on during the Cold War? Personally, I'd nominate them as the programming languages that will outlive us all...
Re:If a technology is outdated, outsource it. (Score:5, Interesting)
So, you didn't like to work on a mainframe, then?
But don't slag off the mainframe just because it is 'old' technology - the PC architecture isn't all that young either, and the mainframe, believe it or not, is in fact very VERY much on the technological forefront, hardware wise. Mainframes had fiber attached disks before most modern developers had heard of networking.
Big to huge institutions don't use mainframes because they are too backwards thinking, but because of reliability. In an industry where downtime costs millions to tens of millions per minute, that counts a lot. On a mainfram you can hot-swap just about everything - not just disks, but everything. And if you wish, you can run Linux on it as well; but it is amazing how often the choice is MVS and COBOL; that is because they are just what you need - not multitools like UNIX and C, just a plain old knife meant for cutting only.
There are only 3 COBOL programs... (Score:4, Interesting)
The "Update"
and the "Print"
At least that's what a lecturer told me many years ago when I did COBOL at uny. I didn't get on with it initially, then I got bored and opened the book... Then I learned that what the lecturer was telling me was his idea of what COBOL ought to look like and not generic. It got a little more interesting after that (along with the student competition to see how many errors we could make the compiler generate with the minimal amount of syntax errors - one mis-placed full-stop managed to get it to the limit of 999 once)
I've not written a COBOL program for over 30 years now. I don't miss it.
-G
Re:Batch (Score:4, Interesting)
Good or bad programming is not defined by the 'style', it's defined by it's readability, maintainability, reusability and efficiency. Yes, there is a right and wrong. Not black and white right and wrong, but certainly tending towards it. Much COBOL code was written by people who didn't understand that either. It works, and solves the immedaite problem in many cases, but it's a difficult to maintain, difficult to read, tangled mess. Yes, there is well written COBOL, but in my experience, it's rare. Personally, I find even well written COBOL difficult to read because of the verbosity. It's like reading a long paragraph of instructions, where a point form list would be easier to read and understand.
Re:Batch (Score:0, Interesting)
Okay, here's the absolute truth about COBOL.
First and foremost, it's a language that cannot muck with the underlying hardware. Period.
IBM will never support anything else on their iron - and I mean never never !!!
It's too much of a revenue stream.
I worked at a place once where we tried to get a C compiler for their mainframe. Ain't gonna happen - on the surface, they appear to provide one.
But that's a façade - an illusion.
Another thing I was told (this is hard to believe) was that protected memory on mainframes is an option. Read my lips - IBM Mainframes do not
have protected memory by default. It's a purchased option. Guess how many IBMs out there do not have this option? That's correct. MANY!
So, a bad C program can toast the OS on many of these machines. So, it's not that COBOL can't be converted, it that the conversion brings with it
a significant risk. Besides, COBOL works. The cost/benefit of converting those many lines of COBOL is the key. A company can upgrade their iron
to a faster box, without touching a single line of code. I'm sad to say that that is the only language in the world that can hold that chalice. C can't
(it's only a portable as its underlying libraries and instruction set size) — nothing else even comes close to COBOL's amazing portability.
CAPTCHA = nights
Re:Batch (Score:3, Interesting)
Re:Batch (Score:2, Interesting)
You probably have not been working with COBOL. The vendors that are supporting it are pushing the technology as much as the C/C++ compiler vendors are.
Re:Batch (Score:4, Interesting)
even tough RPG is ill-reputed as an old static programming language this looks somehow like any other high level language and anyone should understand what's going on here without trying to figure out what that strange INSPECT does
Back in the late 80's early 90's, I was a co-op for IBM. I wrote an RPG program to rearrange some data file. Because of scope, the program had to be reviewed by a senior programmer.
"This is just a start. Where is the rest of it. Do you need help?"
"No. It is complete. Sample input and output files right next to it. I used the cycle"
"The cycle still works?!"
I had learned RPG II in HS. The cycle is all that was needed. He showed that program to every programmer that walked into his office.
The deal it that it all keeps working.