Don't Count Cobol Out 274
Hugh Pickens writes "Although Turing Award-winning computer scientist Edsger Dijkstra once said, 'the use of Cobol cripples the mind; its teaching should, therefore, be regarded as a criminal offense,' Michael Swaine has an interesting entry to Dr. Dobb's Journal asserting that Cobol is the most widely used language in the 21st century, critical to some of the hottest areas of software development today, and may be the next language you'll be learning. In 1997, the Gartner Group estimated that there were 240 billion lines of Cobol code in active apps, and billions of lines of new Cobol code are being written every year. Cobol is a key element in the realization of modern distributed business software architecture concepts — XML/metadata, Web Services, Service Oriented Architecture — and e-business."
Another one? (Score:5, Insightful)
Dijkstra was not known for being conservative in his statements of opinion. His "GOTO considered harmful" essay did a lot of good, but it also did quite a bit of damage. To the point where we ended up with a variety of "considered Harmful" Considered Harmful [meyerweb.com] essays.
(I wonder if ""Considered Harmful" Considered Harmful" Considered Harmful is soon to follow? Oh wait. That already happened [purdue.edu] in '87.)
A more conservative viewing of COBOL would show that it held a useful place in history, but is now antiquated. You'd need to be extremely conservative to think that COBOL has a place for growth in the modern world.
Oh snap. We got another one.
Let's be realistic here.
1. 1997 was 11 years ago
2. Everyone was preparing for Y2K
3. Those billions of lines of code were often replacing billions of lines of coded that were removed
As someone who once worked with mainframes, I can tell you that COBOL isn't dead. However, it's not exactly thriving, either. Legacy systems do their jobs well, so there is little reason to replace them. Instead, many companies use technologies like Java->CICS connectors to bridge the gap between old and new. But that doesn't mean that anyone is going to be developing "millions of lines of COBOL".
Quite the opposite, in fact. Business moves more quickly today than in any period in history. And with business moving so quickly, companies find they need to develop new aspects to their businesses. Those new aspects often take the form of new opportunities to develop new software.
If anything, I think COBOL is still hanging on because the mindset for technology is still external facing. Remember the Dot Com Boom? Well, one of the side effects was that technology shifted from optimizing internal operations to interacting with customers directly. Which is not a bad thing, except that internal operations shouldn't be neglected. Thus I see a lot of companies with inefficient internal procedures because they have not invested in proper internal technology infrastructure. This has left a niche where old COBOL programs are nursed along despite a growing amount of manual work for employees at many companies.
Wouldn't it be nice if technology could solve their problems? Well, it can. All we need is someone to make the investment.
With the economy going bust at the moment, I have a feeling the pendulum is going to swing back the other way. Companies are going to need to tighten their belts and become more competitive on price. Which means that they need more efficient operations. With the massive advancements in technology and ensuring code quality in the last 10 years, I fully expect that companies will soon have systems every bit as solid as their COBOL mainframes. Except they will be designed with more rapid change and flexibility in mind.
No (Score:3, Insightful)
Best Part (Score:5, Insightful)
It may seem surprising that it takes any programming at all to implement a salary change in a payroll system, but a commenter on Slashdot said it was at least plausible, and that's good enough for us.
I think this alone should be enough to discredit the author.
ROI (Score:5, Insightful)
What many people don't get is that a good business person goes after ROI. If you spend money on something, you want to get money out of it. Squeeze every dime until it screams (which I respect, BTW). Ripping out something just because it isn't cool doesn't play. Enhancing or building on top of it when there is a good business case does play. If it ain't broke, don't fix it.
Having to upgrade every 3-5 years means no ROI. This is a great argument against closed source proprietary vendors.
BTW, there is OO COBOL out there. And FORTRAN 95 is OO as well, which I am ramping up to do a project in soon (I hope).
No way (Score:5, Insightful)
and may be the next language you'll be learning
Just impossible. Basically because it was the second language (after FORTRAN) that I learned. I don't really understand the fuss about COBOL. Never found it either much worse or much better than other languages. The thing to remember about COBOL is that it was developed to solve a specific kind of problems. Today we would call it a Domain-Specific Language. And that kind of problems it solves with relative straightforwardness. Most of the critics I see of COBOL are for trying to use it as a general-purpose language. I mean, you don't try to write a text editor in PL-SQL, even if you probably could. And nobody criticizes PL-SQL for that reason.
So COBOL is outdated and verbose. True. So what. It's been years since a wrote a line of the beast, but I wouldn't have a problem to start working with it tomorrow. Also, as the set of problems that it was designed to solve was reduced, it as very pliable to being automatically generated.
So, a language is a language, all have their problems and advantages. Me, I care much more about the size of my screen or the strength of the air conditioning in my workplace than about the particular dialect that I have to program this week.
Bollocks (Score:2, Insightful)
Seriously I can't think of something that is more rubbish. Yes COBOL is out there, but as a mainstay of XML and Web Services? Are you serious? Have you tried getting an old mainframe to talk in Unicode? COBOL is what old apps are written in and what they are maintained in, its not that there are no jobs but you'd be nuts if you are a talented coder to get into COBOL. If you are 50 and want a pension however its an ideal area to get into.
Yes I know COBOL, yes I have developed and maintained in it, and NO it isn't the next thing, its the crap that people wrote when the average IQ in Computing was miles higher than today but the tools were miles worse. What I really pity is the people who are maintaining C++ developed in the 90s. That stuff sucked.
Re:Best Part (Score:2, Insightful)
Re:Why is Cobol hated? (Score:3, Insightful)
You picked the wrong choice to show him why COBOL is hated.
Typical Mainframe COBOL [99-bottles-of-beer.net]
Re:Another one? (Score:4, Insightful)
Yes and no. In the financial industry, for example, COBOL mainframes hang on primarily because their reliable.
BS. In the financial industry COBOL mainframes hang on because they're PAID FOR.
Re:ROI (Score:5, Insightful)
Well, that's a matter of being in a hurry go get the program out the door. There's lots of parameter input through the compiler going on. Always has been.
I personally like terse languages, but I think coupling is a bigger issue. Fifty lines of self-contained COBOL are easier to understand than twenty lines of highly coupled Python that depends on assumptions spread far and wide in the system.
One of the reasons that so many COBOL systems remain is that they were written in a day when most tasks ran top to bottom. It was before the "event loop" became a familiar pattern to most programmers. In a sense, it shows how reusability can shoot you in the foot (there's few worthwhile tools that can't be dangerous some of the time). Back in the day the vast majority of programs had well defined input, performed a well characterized calculation on that input, and produced a well defined output. Now consider something that is a component in a framework. It has to be damn well conceived because it's meant to operate in situations the designer has never even conceived of.
So, I'll bet that the COBOL that survives is stuff which does something that is clearly defined, simple, and useful. Why convert it to Java if it works fine and is part of a large body of software that works fine?
Re:Baby Boomers + COBOL (Score:1, Insightful)
The old "sunk cost, cognitive dissonance" argument.
You might say something "works just fine" but I, e.g., the VP of operations who gets to decide, might say it needs to be improved, that "just fine" is not going to be sufficient for our future.
Re:Why is Cobol hated? (Score:3, Insightful)
SO?
Comparing the number of lines is a waste of time and shows a lack of knowledge about what is actual important about programming.
Most people don't understand COBOL, and there for think it's bad becasue its old and give crappy examples the show how ignorant they are.
Re:ROI (Score:3, Insightful)
Now this doesn't mean you always upgrade to the flavor of the month, but you should look at potential losses as well as potential profits when making a tech decision.
Re:Why is Cobol hated? Recursion (Score:3, Insightful)
Ever tried doing recursion in early Cobol? Maybe they've fixed this in later versions, but in the past the return pointer was stored in program space at the head of the function. This means that if you ever had any recursion, the return would loop back forever. How's that for a 3rd generation imperative language? You have to implement your own call stack!
My main complaint is the verbosity of the language, and the clunky set of program flow verbs. It almost forced you to use GOTO (and indeed, many people used GOTO as a way of implementing exception logic).
It had a couple of nice features for business applications: built in decimal arithmetic, and character-by-character print formatting (less messy than eg Fortran was at the time).
It is "evil" in the sense of being a poor language to teach programming. It is not general purpose enough, which means that students of the language are being constrained in their thinking about how to solve problems ("crippling" the mind).
I have no problem with using it as an application specific language, but surely now there are better choices even in that niche (for example the various database languages).
Let me ask you, what would you replace COBOL with? (Score:2, Insightful)
I keep hearing "COBOL is dead", "COBOL IS NOT DEAD".
But if COBOL were to go, what could replace it?
Requirements would have to include:
- performance (when processing millions of transactions)
- reliability (both hardware & software base)
- maintainability of code (easy for someone to take a program they never seen before, and make needed changes)
- follows business logic
- widely used