Why COBOL Could Come Back 405
snydeq writes "Sure 'legacy systems archaeologist' ranks as one of the 7 dirtiest jobs in IT, but COBOL skills might see a scant revival in the wake of California's high-profile pay-cut debacle. After all, as Fatal Exception's Neil McAllister points out, new code may in fact be more expensive than old code. According to an IDC survey, code complexity is on the rise. And it's not the applications that are growing more complex, but the technologies themselves. 'Multicore processing, SOA, and Web 2.0 all contribute to rising software development costs,' which include $5 million to $22 million spent on fixing defects per company per year. Do the math, and California's proposed $177 million nine-year modernization project cost will double, McAllister writes. Perhaps numbers like those won't deter modernization efforts, but the estimated 90,000 coders still versed in COBOL may find themselves in high demand teaching new dogs old tricks."
No Thanks (Score:5, Interesting)
I learned COBOL in college 20 years ago. I hated it and immediately knew COBOL, TSO, JCL, CICS was not for me. The user was shielded from the complexities of the system, whereas Unix and 'C'... everything was there to learn and discover. No 2-inch IBM manuals to sift through.
Now I work at a place w/ the dinosaur and DB2/COBOL on the backend and I am forced to fix the crap COBOL code written by folks who are long retired. And it sucks... big time. And why these 50-something COBOL programmers think they are hot stuff is beyond me. COBOL is EASY compared to C/C++ or even Java/C#.
The sooner the dinosaur is extinct... the better.
A Question For SW developers? (Score:3, Interesting)
Does this make sense? As a HW person, I dont have a clue, but I would be curious to know what the conventional wisdom is here. Should this stuff be used in an obsolete language, using code constructs that were dictated by HW limitations (Y2K and 2 digit nonsnense) OR Should this be done in something that is HW independent (Java - if I can show my ignorance here) or something like C++?
Teach me here folks!
Re:I don't get it (Score:1, Interesting)
KISS (Score:4, Interesting)
Keep IT Simple Stupid.
No, not it, IT.
Keep Info Technology Simple. We tend to want to add in all the bells and whistles we "want" but don't "need" because we can.
When I build a system from scratch, it is fast, clean efficient. It has everything one of the user "needs" to do their job. It is fast, efficient and clean. And it doesn't have problems if they keep it that way.
But they start adding in all the add-ons, upgrades, multiple versions of the same basic tools. Google, Yahoo, Myspace, Coupon cutter, Weatherbug, Ding (SW Airlines) etc ....
Then they start to complain about how "slow" and "Buggy" the computer is. All those bells and whistles do nothing but distract the user from doing what he OUGHT to be doing.
I see this within applications as well too. Feature creep is a real problem, as is trying to over simplify the front end, at the expense of the back end.
Take a look at the comparison of Vista and XP, there is NOTHING in Vista that is really "needed", but it is a bloated mess when compared to XP. why?
They don't want to KISS, they want "fancy", and fancy breaks, and is more expensive to fix when it does.
Re:I don't get it (Score:2, Interesting)
COBOL itself isn't all that hard. What you also have to know is the stuff that goes with COBOL on a mainframe environment like CICS (pronounced 'kix') and so forth. And then there's the difference between theoretical knowledge and real world experience. It's one thing to learn C by reading K&R, it's another thing to apply that knowledge to writing a real application or a piece of system software.
Just because you can learn COBOL doesn't mean you can match skills with some of those 90,000 coders.
(Spoken by someone who actually knows COBOL, and has actually written a real-world application in COBOL).
Re:Who Cares What Language, It Reeks of Poor Desig (Score:5, Interesting)
yeah, as a software archeologist myself, i can testify that old systems still need maintenance: new laws, changes in organization, new products,... that means that those old systems all need continuous 'fine-tuning' - no administrative program really is 'complete'; to make matters worse: those systems get more and more complex. While a complete rewrite could save money in the long run, in the short term this would be very costly.
I am happy (Score:2, Interesting)
I am so glad that COBOL is not a sexy language. Why? Because it keeps the majority of coders out and keeps the need for developers at a high premium. This allows those of us that know COBOL and actually enjoy coding it to laugh all the way to the bank.
I have been coding COBOL/DB2 for ten years now and have never once felt that I could not get another job doing the same thing making the same or more money.
You can make the statement that COBOL is a dead language all you want but banks, insurance companies, telecoms, energy companies, etc. will continue to use and develop new project around COBOL because "no one has ever been fired for going blue".
You go ahead and continue to develop your little web apps and I will know I have a stable job out look for the next 30 years.
Re:I don't get it (Score:5, Interesting)
I'm a full-time COBOL programmer with a history in Java professionally and C/C++ and a number of other languages in my own company.
COBOL isn't hard to learn. It certainly isn't much more difficult than any other modern language.
The hard part is that COBOL really doesn't help you much. In most modern languages you can just grab a library containing a complete linked list or efficient sort algorithm. COBOL programmers actually need to know how stuff like this works. Now maybe you're an exception, but surprisingly many Java developers don't know the first thing about basic algorithms and memory structures like that. Add to that the need for high performance (the cost of running a COBOL program is often charged by the minute and measured in fractions of seconds), high stability (I've worked with code which could bankrupt a company if not fixed within a week or so) and the complexity of the typical Mainframe environments COBOL runs on, and you can see why it isn't trivial to start working with COBOL.
The language is easy, using it is not.
Re:I don't get it (Score:3, Interesting)
It's not hard to learn COBOL. I think there is even a COBOL for DUMMIES book. If not, I'm sure there is a SAMS learn it in 24 hrs book.
The problem is being book learned is nearly useless. You need to have a skill set to know what VSAM, flat files, etc are. What JCL and TSO is and how to use it, etc. This just to get to the point where you can actually look at the code and compile it.
Now, if your looking at a good piece of structured COBOL code, changing it isn't too hard. The problem thrown in your way are usually administrative - it takes 4 hrs to actually code the change but 4 weeks to do all the documentation of the change, QA, change control, etc to get the code into production.
Now, if your looking at a bad piece of COBOL code, then it could take a very long time to even figure out what is happening in the program. But this no different than trying to update a poorly written piece of C code.
Imagine needing to update a very complex poorly written piece of Code say of the complexity of Nethack (source is freely available). Now suppose there there is little or no doc to the code and you are fresh from a book on C. I think it would take you a long time to make a complex change to the source code.
So at that point the language is basically irrevelant.
Re:"find me a college that teaches it" (Score:5, Interesting)
DeVry does, or at least did, a few years ago. I should know, I took the class. It was an upper level course, and part of a set of required electives. You had to take COBOL or (something) or (something). I don't even remember if the other two were languages or theory or what. But it was there. All campuses don't have to teach it, it is market driven. Having a very large and old telephone company not to far away means there is some demand for people who have had some exposure to the language.
As some others here have commented, COBOL is amazing. I learned programing through BASIC, HyperScript, C, Java, and other languages. COBOL is so primitive in so many ways. It feels a bit like trying to use your knowledge of Romance languages to decipher how to say something in Japanese.
Now this makes sense, as COBOL was designed so long ago for machines that only had punch-cards and such. But for most any student who learns programing these days to be given COBOL is going to be a huge logical shift.
And that doesn't include the syntax. Ignoring the special columns and such, no modern languages are very close to COBOL's syntax.
If they pay for it, I'll learn it (Score:2, Interesting)
If I'm told by my company to learn COBOL and it's on their dime, I'll learn it. Why should I care one way or the other? It's just another language to know.
Zealots aside, if it's needed then learn it. It might not be as 'sexy' as the newer stuff out there but if it keeps me employed and puts me into a hard-to-do-without niche I'm perfectly happy.
Then again I may be the exception in that I'll learn anything my company needs me to learn. There's a few languages I've learned on my own, for my own reasons, but overall I'll take any training they're willing to dole out. Kind of like the reward pellets. I'll keep whatever I learn no matter where I go so I don't see a downside.
Re:Who Cares What Language, It Reeks of Poor Desig (Score:5, Interesting)
Payroll is one of the BEST applications for COBOL. It's very table driven and procedurally oriented. There are very specific discrete steps to be taken when calculating gross pay, pre-tax deducations, tax deductions, and final deductions. Then calculate where the net pay is distributed via EFT or paycheck, create files or print checks, and you are done.
I managed a COBOL based payroll system back in the 80s with green-screen interface, and it was one of the easiest systems to work on. It was written in discrete elements that were easily changed without impacting other programs. New programs could be easily added into the stream. Any system that is well designed can be simple to extend.
That crap about not being able to roll back sounds like someone who doesn't know how to write maintainable code. And anyone who doesn't do backups (or make sure the daily ones were done) before installing new code is an idiot.
I just got through migrating an 8 year old C++ system to Java because it was an abysmal failure that no one wanted to touch. Replaced 12 programs that basically all did the same thing with 1 program and 2 stored procedures, reduced complexity, and increased flexibility.
No language is immune to bad development.
Re:Who Cares What Language, It Reeks of Poor Desig (Score:4, Interesting)
I agree; the stuff worked well in old systems. It was optimized to save CPU cycles and disk space...It was a conscious decision which made good use of the resources of the day.
Unfortunately that day is gone. We should focus now on code reliability and maintainability and COBOL is not great in those areas. Trying to write in intelligent failure into a COBOL app is a nightmare compared to JAVA where it's almost the backbone of the whole language.
Re:Who Cares What Language, It Reeks of Poor Desig (Score:3, Interesting)
What it does have is inertia. It works, right? Why replace it? It's the product of decades of business evolution, do you think you can replace that overnight? New code will never be as good.
State governments are paying millions and millions of dollars to replace their legacy COBOL based systems, so the question of "Why replace it?" has some pretty convincing answers...
Re:I don't get it (Score:3, Interesting)
You mean like all the senseless boilerplate crap that you have to use to write C++ GUI programs on Windows??
Crap is crap, either learn it to do your job, or go find another job because you aren't clever enough.
And, just like with C++, once you create a template, it's just fill in the blanks. I had four COBOL skeleton programs back in the 80s that I used, and they covered 90% of all the programs we wrote. The great part was all the programs had the same structure, so a program I wrote was easily understood by someone else.
One of the developer came to me one day and explained a problem he was having. He started to hand me the printout, and I told him what the problem was without even looking at the code. Why?? Because all of our programs looked the same. And I had made the same error before.
Re:Highly unlikely (Score:4, Interesting)
Not hardly. I just rewrote a VB 3-6 application into C#.NET because nobody can compile it anymore (requires a 16-bit tab component and nobody has VB4 16-bit install disks, let alone floppy drives even if we did).
The original application was 13,000 lines of BASIC, written (mostly full or half time) over the span of 11 years. The new C# application is 900 lines and has MORE functionality (not to mention nice commenting as opposed to NONE) and I wrote it in 2 months.*
Return to the bad old days of underpowered languages that require thousands of lines to read a database and display it on the screen? No thanks.
*BTW, this brings up a good point. Just because some company has 9 million lines of COBOL doesn't mean that the programs couldn't be replaced with 500,000 lines of an OO language.
Re:Who Cares What Language, It Reeks of Poor Desig (Score:5, Interesting)
The voice of experience. I'm constantly amused by posters who think they "know" the answer and it's so simple, everyone else must be dumb. Yet they've never had to execute a project of that magnitude. This entire topic really has very little to do with COBOL and more to do with the issues you raised (as well as the numerous other ones that will be discovered as you walk through each of the questions you listed).
Re:COBOL has loops? (Score:3, Interesting)
> Unless you consider GOTO a loop constructor...
Why not? Ultimately, the compiler is going to produce the machine language equivalent of a goto anyway, so what difference does it make if you have to hand code the initialize, test, iterate portions of a loop or if the language has it all packaged up for you?
Granted it's been over 20 years since I worked on a COBOL program, but the last guy I worked for had developed some pretty decent coding standards that let us use a fair amount of structure in our programs. It wasn't perfect, but I know for a fact that the number of late night phone calls I got went way down after learning to do it George's way.
Re:Who Cares What Language, It Reeks of Poor Desig (Score:4, Interesting)
The language itself is fine. Yes it's verbose, and yes it's old, but it does what it needs to do, which is solving business problems. Look, you need to keep a historical perspective here. COBOL was created back in the "bad old days" before all the best practices were written, because at the time they were still being written.
Ever heard the phrase if it's not broke don't fix it? By your logic we need to pull out core modules in the Linux kernel just because they've been in there for 10+ years! (Note: I don't actually know what the lifespan of code in the kernel is, but you hopefully get my point.)
Not to ruin your rant here or anything, but you're comparing a modern language using a modern transactional db with a legacy language using a legacy db. Of COURSE you're going to see a difference in your ability to recover from a failure! It's not as if you can't code for a proper recovery in COBOL if you're using a modern transactional db on the backend.
I think you're forgetting why most of us are employed as developers. 95% of us (I'm speaking about employed devs, mind) are not here to write code simply to write code, we're here to solve problems, and most of the time that is for a business that is out to make money. Also most of the time if there is no business case to update the code then it doesn't get updated. As for outdated models, how is it outdated if the model still serves it's purpose?
Re:Who Cares What Language, It Reeks of Poor Desig (Score:3, Interesting)
Rewriting software should always be the last resort.
not if you could go from COBOL to a language that supports classes, or even just more modularity would be great ...
Re:I don't get it (Score:4, Interesting)
Re:Who Cares What Language, It Reeks of Poor Desig (Score:2, Interesting)
It is possible to write good COBOL :-)
In the programs I maintain, the recovery is per-program or per-job. Each "unit" of work has a documented (albeit manual) rollback. It usually implies replacing the trashed files from a backup tape (*).
Manual well documented recovery has an advantage : it requires that someone actually looks at the problem and finds why it crashed.
(*) Yes, we don't have a relational database on our mainframe. Only flat files. With 8-chars names. And no hierarchical filesystem. It's called "DOS/VSE with ICCF" and it's so old I feel like a caveman, which is actually kind of fun sometimes :-)
Re:Who Cares What Language, It Reeks of Poor Desig (Score:3, Interesting)
The language itself is fine. Yes it's verbose, and yes it's old, but it does what it needs to do, which is solving business problems. Look, you need to keep a historical perspective here. COBOL was created back in the "bad old days" before all the best practices were written, because at the time they were still being written.
I don't see that this has anything to do with whether COBOL is an OK language. This means that it was an OK language (or maybe even a good language) in the "bad old days", but Moore's Law has given us the luxury of having much higher standards now.
COBOL, FORTRAN and mainframes (Score:3, Interesting)
We have been predicting the demise of both COBOL, FOTRAN and mainframes for how long, now? Decades? I have suspected for a long time that we are not going to lose them any time soon - COBOL is certainly no beauty, but it is proven and seems rock solid. And it is not even all that bad a language to work with, although I must admit it looks rather painful, doing anything but simple programs with it. Still, I worked with COBOL for years - and enjoyed it too.
The same goes for FORTRAN: an ugly language with some horrifying features; but one that has a huge, old code base in the science community - because it was first, but also because it has the exactly the features you need for numeric programming. A bit like a meat cleaver - not a thing of beauty that your girlfriend would have on her make-up table (depending on your relationship, of course), but functional and to the point.
Re:Just translate COBOL to C++. (Score:3, Interesting)
Or, better idea, translate all the COBOL to C++ [mpsinc.com]. No teaching needed.
Actually the link you provided has converters from COBOL to "C", "C++", "Java" and "C#". If these converters/filters produce anything like the output of yacc and lex (open source bison and flex) then the code while runnable is more or less unmaintainable but not to worry you have a job for life if you want ;-)
If you read the following [wikipedia.org] the best quote on cobol is as follows:
Critics have argued that COBOL's syntax serves mainly to increase the size of programs, at the expense of developing the thinking process needed for software development. In his letter to an editor in 1975 titled "How do we tell truths that might hurt?", computer scientist and Turing Award recipient Edsger Dijkstra remarked that "The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense".
Hey it's a quote so please don't shoot me!