Slashdot Mirror
Why COBOL Could Come Back
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."
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.
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.
Agent K: A *person* is smart. People are dumb, stupid, panicky animals, and you know it.
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.
Yes, I'm left. You have a problem with that?
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.
Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
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.
Comment forecast: Bits of genius surrounded by a sea of mediocrity.
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.
I rarely read replies, it's my opinion and if you thought about your opinion a little more, I'm OK with that.
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.
ad logicam Claiming a proposition is false because it was presented as the conclusion of a fallacious argument.
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.
Peter predicted that you would "deliberately forget" creation 2000 years ago...
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).
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?
God, schmod. I want my monkey man!
Cobol was never a good language, and computer scientists fought hard to move the industry away from it because the probability of writing defective code was extremely high. It is readable, but really only in the same sense Intercal is. There are many, many hundreds of programming languages out there with far more programmers in each than Cobol has ever had. Use what makes real sense, not what some medieval history teacher thinks ancient civilizations may have liked. Hell, ADA has more merit - and more support for modern capabilities. If people are really serious about Cobol, I'm going to write an Algol65 plugin for Firefox - see how people like Algolscript pages. Nyah!
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)