×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

COBOL Turning 50, Still Important

Soulskill posted about 5 years ago | from the legacy-code's-legacy dept.

Programming 314

Death Metal writes with this excerpt from a story about COBOL's influence as it approaches 50 years in existence: "According to David Stephenson, the UK manager for the software provider Micro Focus, 'some 70% to 80% of UK plc business transactions are still based on COBOL.' ... Mike Gilpin, from the market research company Forrester, says that the company's most recent related survey found that 32% of enterprises say they still use COBOL for development or maintenance. ... A lot of this maintenance and development takes place on IBM products. The company's software group director of product delivery and strategy, Charles Chu, says that he doesn't think 'legacy' is pejorative. 'Business constantly evolves,' he adds, 'but there are 250bn lines of COBOL code working well worldwide. Why would companies replace systems that are working well?'"

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

314 comments

Oo, oo, oo! I know! (5, Insightful)

Samschnooks (1415697) | about 5 years ago | (#27542181)

Why would companies replace systems that are working well?

Because the director of IT or whatever his title is will want to be able to put on his resume that HE moved a company from a "Legacy" and "Outdated" system to a modern "web based solution" that enables "greater productivity" among the workforce saving "millions of dollars". Now, he can put that on his resume and go for the CTO, CIO, or whatever jobs.

I've seen it and it works.

Re:Oo, oo, oo! I know! (3, Informative)

Jurily (900488) | about 5 years ago | (#27542221)

Because the director of IT or whatever his title is will want to be able to put on his resume that HE moved a company from a "Legacy" and "Outdated" system to a modern "web based solution" that enables "greater productivity" among the workforce saving "millions of dollars". Now, he can put that on his resume and go for the CTO, CIO, or whatever jobs.

If and only if they're able to pull it off. It's also a nice way to end your carreer if you fail.

Re:Oo, oo, oo! I know! (4, Insightful)

plopez (54068) | about 5 years ago | (#27542391)

If and only if they're able to pull it off. It's also a nice way to end your carreer if you fail.

no, you collect a bonus and bail out before it crashes in flames leaving someone else holding the bag. See also the bank failures for examples of this. See a pattern? I hate MBAs.

Change company (1)

krischik (781389) | about 5 years ago | (#27542469)

If and only if they're able to pull it off. It's also a nice way to end your carreer if you fail.

Just change company before failure becomes apparent. Then you prepared it all so well and successor just it all up.

Re:Oo, oo, oo! I know! (4, Funny)

fuzzyfuzzyfungus (1223518) | about 5 years ago | (#27542239)

I'm guessing that this story involves enough java to float a battleship; but not quite enough to keep the interface responsive...

Re:Oo, oo, oo! I know! (1)

Fnord666 (889225) | about 5 years ago | (#27542373)

I'm guessing that this story involves enough java to float a battleship; but not quite enough to keep the interface responsive...

Right, because we all know that if an application is slow, the solution is to add more Java.

Re:Oo, oo, oo! I know! (1)

RichardJenkins (1362463) | about 5 years ago | (#27542477)

You're approaching IT Nirvana when you understand that whatever the question, the solution is to add more Java.

Re:Oo, oo, oo! I know! (5, Funny)

Tubal-Cain (1289912) | about 5 years ago | (#27542509)

How can I be more alert in the morning?

add more Java

Hey, you're right! That really is the solution!

Re:Oo, oo, oo! I know! (2, Interesting)

freegamegallery (1525101) | about 5 years ago | (#27542399)

Well, yes, that could be part of it. The other part of it is that in smaller shops you have a talent pool to pick from, and getting cobol programmers isn't easy, especially ones who are also proficient with some of the modern programming languages and web development. I'm not saying it can't be done, but its harder to find those folks. Plus, cobol programmers are usually older, have much experience in the industry, and consequently command a higher salary. Sticking with the "more modern" technologies in my mind really translates into using the technologies that are most popular giving you a large pool of applicants to hire from at an affordable rate.

Re:Oo, oo, oo! I know! (1)

darkwing_bmf (178021) | about 5 years ago | (#27542413)

But by that logic, wouldn't it make more business sense to hire a couple of older programmers to maintain a system that works than a bunch of newbies to rewrite it?

Re:Oo, oo, oo! I know! (4, Interesting)

coryking (104614) | about 5 years ago | (#27542921)

Depends. Staffing is one bit of the equation. You've also got to factor in "how easy is it to extend our existing application". Can you tie your COBOL stuff into your customer-facing billing system on your website? Can your call center be updated so the CSR's are all doing data entry on a web app or a "real" desktop application? I'm sure both are possible but I'm also sure both have price structures that are insanely high, but just a notch less insane as "hire a team of devs to dump COBOL"

There is one more thing I'll toss out, but I'm not sure about. Location. If you are located in Bumbleskunk, USA, the talent pool is pretty small and you will have a hard time getting programmers to relocate (after all, if your company sucks, they are basically gonna have to move again to work some place else). I wonder if there is any correlation between "Uses COBOL" and "Is located in Bumbleskunk". In other words, how many companies headquartered in say, Boston or Silocon Valley use COBOL vs how many companies in say Cowtown use COBOL.

Re:Oo, oo, oo! I know! (0)

nametaken (610866) | about 5 years ago | (#27542441)

I've seen it and it works.

Note to self!

COBOL Turning 50, Still Important

But still, this sounds awfully defensive. ;)

Re:Oo, oo, oo! I know! (1)

kilodelta (843627) | about 5 years ago | (#27542561)

So very true. IT Directors always try to put their stamp on things. I should know, I was an I.T. Director once.

Re:Oo, oo, oo! I know! (2, Interesting)

jlp2097 (223651) | about 5 years ago | (#27542609)

Your answer, while maybe true in some rare cases, just shows the ignorance of some IT people to business decisions. Maintaining such an old piece of technology might actually result in higher costs than developing a new system based on current technology. Why?

1. People. Probably the most important reason. Cobol is not exactly a widely taught language. People knowledgable in Java, C#, PHP and other languages are younger, much easier to find and thus cheaper. People with real solid Cobol experience are actually quite expensive nowadays (supply->demand).

2. Extensibility and maintainability. While maintainability might be ok, extensibility is a bitch. Connectors to Web Services? Talking to the myriad of other web apps you have inhouse? Accessing that SAP system you have?. There might be some solutions for every one of those problems. Hell, they even made Object Oriented Cobol a decade or so. But all of these (proprietary) solutions cost much more money than simply using a new language / technology which comes with most of these included.

Inhouse web apps? (3, Insightful)

ClosedSource (238333) | about 5 years ago | (#27542935)

In a lot of environments in-house web apps would only serve the purpose of being trendy. I suspect a company who is smart enough to keep their working code around would probably resist the temptation of unnecessary "webizing" their internal apps.

It's the maintenance, stupid. (2, Insightful)

SanityInAnarchy (655584) | about 5 years ago | (#27542747)

Sure, greater productivity is one benefit, but the language is completely irrelevant for that.

It's about how flexible the system will be when you have to change it. And you will -- that's the whole point of software, that it is soft, and changeable.

Old Cobol apps generally are not flexible [msdn.com]. (stolen from this comment [slashdot.org]). It's worth mentioning that a decent object-oriented system would've gone a long way towards eliminating this problem -- any idiot can stuff a date into a Date class, which then encapsulates all the date-handling code.

Maybe some of it is very well designed. Drupal [drupal.org] proves that you can write good, elegant code in any language, even if you are fighting the language and reinventing the wheel every step of the way. But the converse [slashdot.org] is also true -- you can write bad COBOL in any language.

My point here is that when changing minimum wage is even a tech [sacbee.com] story [slashdot.org] at all, that program is really fucking broken*. It's very likely too broken to be patched. Really, we've learned things in the past 50 years, and not all of them are buzzwords or ways to waste five times the RAM.

Not all of them have anything to do with programming languages, either, but if you're building a new system, and you have a choice of languages, why would you choose COBOL?

I agree in spirit. But what people have to remember is, if it ain't broke, don't fix it. So, if it's broke, fix it!

* I apologize for the profanity, but any program that can't change a fucking constant is a broken program. Or did they copy/paste 6.55 all over the place?

Re:It's the maintenance, stupid. (1)

ClosedSource (238333) | about 5 years ago | (#27542973)

It's about how flexible the system will be when you have to change it. And you will -- that's the whole point of software, that it is soft, and changeable."

Not entirely. Software allowed one to perform functions that were not practical to do in hardware.

Re:Oo, oo, oo! I know! (1)

rackserverdeals (1503561) | about 5 years ago | (#27543025)

You have to understand where many of the cobol programs are running and what their function is. They're not little shell scripts people wrote for fun. They usually power the core of large businesses and depending on the business could be responsible for millions or billions of dollars in trasactions a day.

Screwing with that, when everything is working fine is not a good idea. When Cobol programmers become even more rare it will become a more desirable job for programmers. I think places like ITT tech and Devry teach cobol to youngins. I don't remember the exact place but I remember running across a couple of them.

Think of it this way. If Apple came out with a new iHeart would you have surgery to replace your perfectly functioning heart with an artificial one just so you can play mp3s?

Why replace it? (4, Funny)

Anonymous Coward | about 5 years ago | (#27542189)

Why would companies replace systems that are working well?

So I can have a fucking job?

Re:Why replace it? (4, Informative)

artor3 (1344997) | about 5 years ago | (#27542297)

Learn COBOL, and you always will. My dad is a COBOL programmer for the NY state government. According to him, around 95% of their COBOL programmers are within 10 years of retirement. The youngin's (as he calls them) are in their mid to late forties.

If you know COBOL, you are absolutely guaranteed a job there.

Re:Why replace it? (0)

Anonymous Coward | about 5 years ago | (#27542501)

So I can have a fucking job?

Since when does anyone have an obligation to provide you with a job? You sound like the American automotive manufacturers.

Re:Why replace it? (0)

Anonymous Coward | about 5 years ago | (#27543031)

Since when does anyone have an obligation to provide you with a job?

Nobody does. Just like nobody has to decide to sell you food out of a supermarket and you would have to move sustenance farming.

COBOL Jokes (0)

Anonymous Coward | about 5 years ago | (#27542193)

Being a new whippersnapper, how about some age old COBOL Jokes?

I'll get off your lawn now sir... ;)

2 jokes, 1 question (1)

Futurepower(R) (558542) | about 5 years ago | (#27542279)

COBOL: Completely Obsolete Business Oriented Language

COBOL in the future [thejokeshop.org]

Why not translate? COBOL to C++ translators [google.com].

Re:2 jokes, 1 question (4, Insightful)

berend botje (1401731) | about 5 years ago | (#27542515)

When you have working code in COBOL, really battle-hardened proven-beyond-doubt COBOL code, would you really trust a mechanical translation into another language?

I wouldn't, no way! And there is no way to completely test the new code either, as the specs never existed or at least are missing and/or outdated.

I'd rather keep the working COBOL code. Even if that means I have to deal with grumpy old geezers to maintain said code.

Re:COBOL Jokes (4, Funny)

larry bagina (561269) | about 5 years ago | (#27542287)

have you heard about object oriented cobol?

It's called ADD 1 TO COBOL GIVING COBOLPLUSONE

Re:COBOL Jokes (3, Interesting)

TheRaven64 (641858) | about 5 years ago | (#27542355)

Surely you mean ADD 1 TO COBOL GIVING COBOL. In C, ++ is an increment, not an add-and-assign-to-new-variable operator.

The CABAL invented it to take over the world! (0, Offtopic)

line-bundle (235965) | about 5 years ago | (#27542197)

I managed to finally figure out their world domination plan!

It's definitely not the Bilderberger group otherwise it would have been called boldorborgor. Naah, too borgish.

Why ... replace systems? (0)

Anonymous Coward | about 5 years ago | (#27542245)

"Why would companies replace systems that are working well?" Strategically, this is a less important question than "would companies know how to replace their current systems if they wanted to (or had to)"? If all of the COBOL-hosted I/O is well-formed and buzzword-compliant, then perhaps it wouldn't matter (at least as long as what runs it can be replaced).

Cool (4, Interesting)

bigsexyjoe (581721) | about 5 years ago | (#27542249)

Does that mean my Java skill set is likely to keep me employed for the next 30 to 40 years?

Re:Cool (0)

Anonymous Coward | about 5 years ago | (#27542265)

Well, C came out in 1972 and is still going strong, not sure how long Java will last...

Re:Cool (1)

larry bagina (561269) | about 5 years ago | (#27542379)

AT&T didn't try to keep control of C. Through the years, there have probably been hundreds (maybe thousands) of implementations and there are published standards (K&R, ANSI/ISO C89,ISO/IEC C99).

Meanwhile, Sun has kept a tight fist on Java.

Re:Cool (0)

Anonymous Coward | about 5 years ago | (#27542423)

No, Java will probably die soon.

Re:Cool (1)

Ilgaz (86384) | about 5 years ago | (#27542481)

Well Java stays for sure. You will just be blamed for not using whatever fashion is. That is exactly happening to COBOL developers which their code still runs unmodifed on some million dollar state of art Z/OS mainframe for 30-35 years. I know a very big bank's very high level admin, the stories he told me were amazing.

People should look below at their shiny, fashion development tools running OS X and they will see UNIX, with exactly same principles as it was invented in 1970s. Thing calls its shells "tty", if one looks up where that comes from, he will be horrified.

I bet as Java developer, you try to stay in JVM 1.4 compatibility if no fancy stuff needed and you have users asking you "Why not use Java 6 (or 7)? 1.4 is old". Of course same people (if they run Windows) will be advertising .NET to you too.

I guess Sun knows the above about fashion and all that "java fx" etc stuff are designed to feed the fashion people :)

Re:Cool (1)

WillKemp (1338605) | about 5 years ago | (#27542951)

Thing calls its shells "tty", if one looks up where that comes from, he will be horrified.

Anyone reading slashdot who doesn't already know where "tty" comes from should hand their geek card in at the door on the way out.

Some of us have even used them!

Define "working well" (5, Interesting)

Just Some Guy (3352) | about 5 years ago | (#27542273)

Before I start, I know all too well that you can write good or terrible code in any language. Still, most COBOL code I've seen is written to run well on hardware that is no longer relevant. A recent experience with an ex-coworker illustrated this pretty well for me:

Said fellow, call him "Joe", had about 30 years of COBOL experience. We're a Python shop but hired him based on his general coding abilities. The problem was that he wrote COBOL in every language he used, and the results were disastrous. He was used to optimizing for tiny RAM machines or tight resource allocations and did things like querying the database with a rather complex join for each record out of quite a few million. I stepped in to look at his code because it took about 4 hours to run and was slamming the database most of the time. I re-wrote part of it with a bit of caching and got the run-time down to 8 seconds. (Choose to believe me or not, but I'd testify to those numbers in court.) I gave it back to him, he made some modifications, and tried it again - 3 hours this time. I asked him what on Earth he'd done to re-break the program, and he'd pretty much stripped out my caching. Why? Because it used almost half a gig of RAM! on his desktop and he thought that was abhorrent.

Never mind that it was going to be run on a server with 8GB of RAM, and that I'd much rather use .5GB for 8 seconds than 1MB for 3 hours of intense activity.

So Joe isn't every COBOL programmer, but you and I both know that he's a lot of them. But back to the direct point, how much of that 250GLOC was written with the assumption that it'd be running on 512KB machines or with glacial hard drives or where making the executable as tiny as possible was an extreme priority? Doing things like storing cache data in hash tables would've been obscenely expensive back in the day, so those old algorithms were designed to be hyper-efficient and dog slow. Whether you think that constitutes "working well" is up to you.

Re:Define "working well" (5, Insightful)

thethibs (882667) | about 5 years ago | (#27542363)

Nice story, but it doesn't say anything about COBOL.

I have a similar story about 30 programmers who spent two years writing java code and delivering nothing useful because the requirement called for two different architectures: one best served with a batch system, the other best served with a real-time system. What they need is COBOL and C, but what they know is java and struts. It's been another four years since I ran screaming from the building and they still haven't delivered anything useful.

Inept programmers will screw things up in any language.

Re:Define "working well" (4, Interesting)

Just Some Guy (3352) | about 5 years ago | (#27542491)

Nice story, but it doesn't say anything about COBOL.

I think it says a lot about The COBOL Way, or at least the way things were done when those ancient codebases were being written.

Re:Define "working well" (1)

chthon (580889) | about 5 years ago | (#27542741)

The problem with Java is that it is too much hyped and sold to business types as the silver bullet. As Fred Brooks said more than 30 years ago : THERE IS NO SILVER BULLET (yelling intentional)! Is Java better than Cobol ? Probably not, as Java is also an imperative language. Do not fool yourself : object-oriented languages of the type SIMULA (and Java is not better than Simula, just the wheel reinvented) is nothing more than an imperative language with a small layer for dispatching on type, be it in the compilation or the run-time. However, Java does have a big marketing machine behind it and a whole lot of people who have stakes in it, and it is hyped in all kind of schools. Java is a success but for the wrong reasons. Compare it with any other type of language and it does not have any more advantages or deficiencies. It is just used much because it sounded cool 13 years ago.

Re:Define "working well" (1)

k.a.f. (168896) | about 5 years ago | (#27542911)

Is Java better than Cobol ? Probably not, as Java is also an imperative language.

Granted, there is hype, and programming is intrinsically difficult. That said, if you believe that language designers have learnt no lessons whatsoever within 40 years, you are delusional.

Re:Define "working well" (1)

chthon (580889) | about 5 years ago | (#27543069)

That is true, but I do not think they implemented those lessons in Java, even when people like Richard P. Gabriel and Guy L. Steele helped developing and implementing the language.

Re:Define "working well" (5, Insightful)

TheRaven64 (641858) | about 5 years ago | (#27542487)

You see that kind of thing from lots of programmers who only know one language well. This is why a good programmer always keeps up with modern architectures. I've seen C programmers who put things in globals rather than passing them on the stack, because that was faster before caching (now it breaks locality of reference, and moves something that was in a register or on the stack to an indirect reference where it needs extra loads and causes extra cache churn).

I've seen programmers who grew up with Pascal carefully turning multiplies into sequences of adds and shifts. Great, except that something like the Athlon can do two multiplies in parallel, but only one shift at a time (because most code contains a lot more multiplies than shifts), stalling the pipeline.

Another common issue is aggressively testing for potential special cases for optimising, ignoring the fact that branches are very expensive on most modern CPUs and the cost of the checks is now often greater than the saving from shortcutting the special cases.

Java programmers are not immune to this, and often optimise based on old versions of the JVM. One favourite is to add finally everywhere, making the code very rigid, believing this makes it faster. In a modern JVM, finally is completely ignored; the VM already knows if a class is not subclassed and will do the same optimisations whether it is declared finally or not.

There's a reason why the rules for optimisation are:

  1. Don't.
  2. Don't yet (experts only).

If you write good algorithms, your compiler will usually produce reasonable code. If this isn't fast enough, then make sure you really understand how your VM and target CPU work, before you try optimising. The experts only part isn't a joke.

Re:Define "working well" (3, Insightful)

david.given (6740) | about 5 years ago | (#27542901)

One favourite is to add finally everywhere, making the code very rigid, believing this makes it faster.

I think you mean final here, no? finally does something else.

  1. Don't.
  2. Don't yet (experts only).

Very true.

I'd also add the additional rule: You don't know it's slow until you've benchmarked it. All too often I have seen, and I should add that I've perpetrated this myself, people spend ages painstakingly optimising parts of a system that felt like they were cause speed problems, when actually they weren't.

I once spent about two or three months designing and implementing a clever caching system for properties in a UI framework. It was subtle and complex, and I was very proud of it, and it was a total waste of time. We eventually threw it all away and stored the properties in an AVL tree. Yes, this involved looking up the properties in the inner loops of all the UI component redraw methods, but compared to the amount of work of touching every pixel on the screen, this was trivial. And it increased flexibility, reduced complexity and code size, and vastly improved maintainability.

Re:Define "working well" (4, Informative)

TheRaven64 (641858) | about 5 years ago | (#27543055)

I think you mean final here, no? finally does something else.

Yes, sorry, final.

And it increased flexibility, reduced complexity and code size, and vastly improved maintainability.

Reducing code size is important for three reasons:

  1. It means that a single human can understand more of the program at a time.
  2. It means that there are fewer places to look for bugs.
  3. It reduces instruction cache usage.

This last part is something I should probably have mentioned in the last post. Instruction cache churn is one of the biggest performance killers on modern CPUs. It is particularly instructive to compare C++ templates and Objective-C. In C++, your compiler will generate a new set of functions for every template instantiation (well, not quite, but close enough). In Objective-C, it will only emit one copy of a method and then use run-time lookups to determine how things work. The Objective-C solution to the problem is slower. You can generate lots of microbenchmarks that prove that it's slower. Except, somehow, the C++ program ends up being slower overall, because the Objective-C program can keep most of the code in cache, while the C++ program is constantly thrashing the instruction cache. If you run a couple of programs concurrently, each one gets even less cache usage, so you end up spending even more time waiting for main memory.

This is almost a corollary to your comment: it isn't slow until you test it in place. On a modern computer there are so many potential sources of performance issues that you can't always take a microbenchmark and generalise it. There are lots of cases where one option is slower when you do it once but faster when you do it a few million times, or faster when you do other seemingly-independent things. Microoptimisations are no longer a good way of ensuring that an entire program runs quickly.

Re:Define "working well" (1)

Workaphobia (931620) | about 5 years ago | (#27543029)

One favourite is to add finally everywhere, making the code very rigid, believing this makes it faster. In a modern JVM, finally is completely ignored; the VM already knows if a class is not subclassed and will do the same optimisations whether it is declared finally or not.

Pretty sure you mean "final" - as far as I know, "finally" is only used in exception handling. Optimizations aside, "final" is still useful for making a statement about the intended terminal status of a class in the hierarchy.

Re:Define "working well" (0)

Anonymous Coward | about 5 years ago | (#27542691)

That's not a story about COBOL, that's a story about old farts stuck in the past.

Re:Define "working well" (1)

Just Some Guy (3352) | about 5 years ago | (#27542719)

That's not a story about COBOL, that's a story about old farts stuck in the past.

Yes, much like the legacy systems we're discussing.

Re:Define "working well" (0)

Anonymous Coward | about 5 years ago | (#27543051)

I'm future you stuck in my past (2009). Don't call me an old fart you insensitive clod!

Re:Define "working well" (0)

Brandybuck (704397) | about 5 years ago | (#27542727)

The is a balance to be struck. I have seen the opposite practice too many times to count, usually involving some fresh young college grad thinks that RAM grows on trees. Or that CPUs are infinitely fast.

Don't prematurely optimize, but at the same time, don't assume that resources are infinite. And when you do optimize, know what you're optimizing for. Because in many domains it is not speed.

Perl, it's the new COBOL (2, Insightful)

Anonymous Coward | about 5 years ago | (#27542293)

COBOL's still around, will perl last as long?

For instance there is now OO COBOL but the only people that use it are COBOL programmers who are stuck, perhaps because of their company's dictates, perhaps by choice, with COBOL. In the same way perl may be heading towards irrelevance wrt "mainstream" language. I've written commercial perl in the past, it was a pain then and it's still a pain now. The thing is that now there are alternative languages in the same space (python, ruby etc., php for web side) that do the "perl thing" better than perl.

Perl was great, it introduced many people to programming, just like COBOL did. But now it's time to move on. To move on to languages that learnt from perl, that improved on it, that don't have to drag around a syntax and culture that values neat tricks and trying to guess what the programmer really meant over providing the needed building blocks and letting you build code that does what you say, not what it thinks it heard you say. Or even, dare I say it, to move on to languages outside the perl family for some programming and choose the right tool for the job for a change.

I'd prefer to think of this as provocative rather than a flame, there is a difference you know.

Re:Perl, it's the new COBOL (1)

Bill, Shooter of Bul (629286) | about 5 years ago | (#27542407)

I agree on you assessment of COBOL, but lay of perl. Its cool like Jazz. It doesn't go out of style. COBOL is more like the US Mail service. Yeah, it works and is dependable and can't be replaced for everything, but generally time has passed it by. There are better ways to send information than mail. So maybe you don't get rich and famous by playing Jazz or coding perl, but there is a certain timelessness poetry to it.

Re:Perl, it's the new COBOL (2, Insightful)

coryking (104614) | about 5 years ago | (#27543027)

You know, I guess it depends. I wouldn't port an application from Perl to something else. But I'm not sure I'd base a new project on Perl either.

There are some things about perl that could be fixed that might change my mind:

1) Dump Perldoc and liberally rip from javadoc [sun.com] and XML comments [microsoft.com]. I know both of these got their start from perldoc, but perldoc needs to catch up.
2) Make sure the IDE actually uses said docs. Once your IDE's intellesense sucks up your comments and uses them while you are typing in a method, you are rewarded for documenting your stuff. Nothing like positive feedback to encourage good habits.
3) Finish EPIC [epic-ide.org]. Perl needs IDE support. Syntax coloring and auto-indentation does not make for an IDE.
4) Get rid of this my $blah_param = shift; crap and start making function declarations that work like everybody else: sub myDopeFunction($blah_param){}. This coupled with perldoc's suckage lead to hard to maintain code
5) Give a couple million to the Template::Toolkit guys. They rock.
6) Mystery option.

DOH! (3, Funny)

Daswolfen (1277224) | about 5 years ago | (#27542305)

That's what I get get for learning FORTRAN in college rather than COBOL...

at least my mad HTML skills..

oh wait... all websites are in FLASH or PHP now...

DOH!

Ok.. im going back to watch a movie on my Betamax or HD-DVD player....

Re:DOH! (3, Interesting)

Brandybuck (704397) | about 5 years ago | (#27542777)

Believe it or not, there is a LOT of Fortran out there. I've run across quite a bit of it in the past few years. A lot of scientific, engineering and other number crunching apps were written in Fortran, and there's no reason to rewrite them just because they're thirty years old. The apps might have brand new GUI and visualization front ends, but deep in the heart there is some Fortran code encapsulating the domain specific math.

Adequate Languages (3, Insightful)

j. andrew rogers (774820) | about 5 years ago | (#27542375)

COBOL is a perfect example of an "adequate" language, like most programming languages that are in common use. Adequate languages linger forever if there is a tool chain to support them because there is little in the way of economic rationale for replacing them.

The reason adequate languages proliferate over the long term is that only inadequate languages get replaced, and "ideal" languages become hopelessly politicized by purists and ideologues, leaving the adequate, practical, boring languages as the sound business choice. It is a real-world example of perfect being the enemy of good enough, but for economic reasons good enough always wins.

Re:Adequate Languages (1, Flamebait)

isdnip (49656) | about 5 years ago | (#27542421)

Good point. COBOL is adequate.

It's just not k3w1. Script kiddi3z don't use it. Hax04 d00dz don't like it. Boring grownups with real work to do use it, and they do real work with it. How uninteresting!

What COBOL won't do well or at all -- write Linux device drivers, write 3D game engines, or overflow buffers and take control of somebody else's system in order to send spam. What it will do -- process lots of data, paying attention to every penny.

C, on the other hand, is a miserable language for almost everything except system-level (kernel, driver) hacking. Its widespread use for many other functions is a stupid fashion.

Re:Adequate Languages (1)

TheRaven64 (641858) | about 5 years ago | (#27542621)

C isn't a great language for low-level programming either. One of the first languages I learned was PL/M. I forgot most of it, but recently revisited it. In comparison to PL/M, C looks like a toy language. PL/M has, for example, much better support for NUMA architectures (this in a language that Intel was pushing for the 8086). Variants of ALGOL were popular for low-level code for a little while, and supported things like concurrency / reentrant code a lot better than C does.

Re:Adequate Languages (better than) (2, Interesting)

OFnow (1098151) | about 5 years ago | (#27542701)

It's more than adequate because it natively handles money data in transparently correct ways. Other languages have to be bent to fit. Integer and double precision data simply do not meet the need, though these days with 64bit integers it is easier to warp integers to be usable.

In addition it let one record right-size fields on disk and tape (in a day when disks were small and very very expensive).

I'm glad I no longer write code in COBOL, but for many years it was the only choice possible for business.

It was amusing in the 60s 70s 80s reading papers suggesting (32bit) integers and double precision (in C or whatever) as an alternative to COBOL data types. I guess the authors never kept their checkbook to the penny or never had as many as 5 billion pennies in that checkbook.

Re:Adequate Languages (1)

Brandybuck (704397) | about 5 years ago | (#27542801)

Cluestick: That hopelessly politicized language is NOT ideal, despite what the purists and ideologues say.

COBOL, not so bad (3, Insightful)

Ancient_Hacker (751168) | about 5 years ago | (#27542437)

As just one data point, a certain place replaced a COBOL app that ran with millisecond response time just fine on a 2 megabyte 1 MIPS mainframe, replaced it with a spankin' fresh Java app that ran about 2000 times slower on an 8 gig 16-CPU, 800MHz very expensive water-cooled mainframe.

Now it could have been due to having a bunch of neophyte Java weenies doing the coding, but I'm just sayin', when there's three orders of speed and 3.5 orders of RAM, there may be something significant in the implementation language.

Re:COBOL, not so bad (1)

Bill, Shooter of Bul (629286) | about 5 years ago | (#27542489)

Yeah, its the coders, not the language. Java is one of the easiest languages to screw up the implementation while still having it "work". Java is flexible enough for bad coders to make a noose and hang themselves.

Re:COBOL, not so bad (0, Troll)

glitch23 (557124) | about 5 years ago | (#27542687)

Java is going to be inherently slower on the same hardware due to the interpeting of the code that it must do. Obviously good coding helps too but there is going to be some inherent latency because of the fact the Java code isn't compiled to machine code.

Re:COBOL, not so bad (0)

Anonymous Coward | about 5 years ago | (#27542839)

Ever hear of JIT compilers? which due to run-time knowledge of the platform and execution patterns might actually compile the code into a more efficient form than a normal compiler which doesnt have that information? Every JVM has a JIT nowadays. And there are some (GCJ atleast) compilers to compile java straight into native code.

Re:COBOL, not so bad (1)

david.given (6740) | about 5 years ago | (#27542971)

Obviously good coding helps too but there is going to be some inherent latency because of the fact the Java code isn't compiled to machine code.

Actually, these days it is, especially on enterprise systems. The latest Java JITs are very, very good, and will emit machine code that rivals C and C++ for most tasks.

The biggest performance hit between Java and C is that Java programming styles involve more dynamic memory allocation than C does --- it's very common to allocate objects that will only be used a few times and then discarded. C doesn't, of course, but at the expense of significantly more complex code.

I have a pet project, Clue [sourceforge.net], which is a C compiler that will compile mostly standard C89 code into source code for dynamic languages like Javascript, Lua, Java, Perl5, etc. The code it produces is crap, but it's still an interesting toy. One of the backend targets is Java. When I do the benchmarks and compare my program, compiled from C into Java and then run on a decent JIT, I see that the Java version runs at 40% of the speed of a native version compiled with gcc.

Given the huge amount of overhead and the fact that Clue itself produces awful code --- Java doesn't support goto, so clue has to emulate them with a while loop around a switch statement! --- that is scarily good.

One day I want to replace Clue's compiler front end (currently based on Sparse) with a better one that generates Java bytecode directly and see what that does to the benchmarks.

Re:COBOL, not so bad (-1, Flamebait)

Anonymous Coward | about 5 years ago | (#27542977)

Obama:"We do not consider ourselves a Christian nation." Our currency, national motto, laws, and morals disagree.

However, our Constitution does agree. And the first three of your examples are unfortunate blatant violations of the Constitution, and should be ignored until they are overturned.

Live a passionate life (3, Interesting)

cryfreedomlove (929828) | about 5 years ago | (#27542451)

When I was working on my CS undergrad degree, more than one professor told me that I was really limiting my job prospects because I declined to take the elective COBOL classes. I knew enough about COBOL then to know that I could not drag myself out of bed in the morning to make a living with it.

The ranks of COBOL programmers out there are living drone like lives without passion or joy. That's not for me. I code for the love if it.

Re:Live a passionate life (1)

Sponge Bath (413667) | about 5 years ago | (#27542585)

...living drone like lives without passion or joy.

Wow. Absolute judgment on the lives of others based on the programming language they use?

Re:Live a passionate life (1)

berend botje (1401731) | about 5 years ago | (#27542595)

Those ranks are collecting a nice, secure paycheck each and every month and will do so for the next few decades.

Coding for the love of it is marvellous, a joy without peer. But without a corresponding paycheck it is just vanity. Mental masturbation, if you will.

I'd rather be a well payed drone than a masturbator, wouldn't you?

Re:Live a passionate life (1)

chthon (580889) | about 5 years ago | (#27542809)

Bah, you do not know what you are talking about. I wrote not only applications in COBOL, but even tools to help automate my compilations, and once even a remote login shell. For every language the Turing principle counts, and if your COBOL gives access to your operating system calls, then the sky is the limit.

Design (2, Interesting)

mrlibertarian (1150979) | about 5 years ago | (#27542455)

Why would companies replace systems that are working well?

The question is not, 'Does the code work?', the question is, 'Does the code follow good design principles?' If the answer is 'No, the code is not well-designed', then maintenance can be very costly. I like the snippet from this [msdn.com] page:

"I was once told by an instructor in a design patterns class that the Y2K problem wasn't caused by using 2 digits to represent 4. Instead, it was caused by doing so all over the place. While the reality of the situation is a little more complicated than that, the principle is true. If the date handling code had been all in one place, a single change would have fixed the whole codebase rather than having to pull tons of Cobol coders out of retirement to fix all the business applications."

Re:Design (1)

bobbonomo (997543) | about 5 years ago | (#27542591)

Partly true. The Y2K think was to save 2 bytes. I remember a similar problem at the time and saying "2 bytes! are you kidding?" The response was "the app has x number of clients and x number of fields. This will save 2 disk spindles". The wise-ass kid (me) turned around, removed foot from mouth, and solved the problem. Oh and it was COBOL.

Spindles were 100MB to 200MB, big like dishwashers, and cost a gazillion plus your next new born.

That is the problem with WGA... (-1, Offtopic)

QuietLagoon (813062) | about 5 years ago | (#27542461)

'Business constantly evolves,' he adds, 'but there are 250bn lines of COBOL code working well worldwide. Why would companies replace systems that are working well?'"

.
That is the problem with Windows Genuine Advantage when used in a corporate environment. It does not matter whether or not the software systems are still working well. There is a remote switch (based in Redmond) that can be used to shut down these functioning systems and force conversions/upgrades. If you do not think it can or will happen, look at the DRM servers that were turned off.

Skill Sets are disappearing (4, Insightful)

1c3mAn (532820) | about 5 years ago | (#27542507)

Why is no one updating Cobol code? Because the skill to interact with other systems is disappearing.

As a Mainframe Utilities Programmer I hear it from customers all the time. "We can't touch that system because the guy who wrote it retired." System here just represent the code, but also the server backend stuff like database design.

I have heard stories of an IT department being 10 man team. In the 80s that team had everyone dedicated in maintaining the mainframes. Now, they still have 10 people but only 1 person is there to work on the Mainframe.

So now you have code from the 70s that no one understands, running a mission critical application, and you think the IT manager is going to touch it? He is praying it doesnt break on his watch or he might get a call from the COO. Even if it breaks, it is better to patch it then rewrite it because the database behind it is so vital to all the rest of the application that it cant be changed either.

The issue mainly is that no one is teaching old skills anymore. Skills that are still required, but really arent 'sexy' for young college students to learn. Even the name "Mainframe" has grandfather connotation to it while if people actually looked at the IBM Z Servers, one would see how high tech these systems actually are.

Re:Skill Sets are disappearing (0)

GigsVT (208848) | about 5 years ago | (#27542825)

"High tech"...

If by "high tech" you mean "pay $250,000 for the same speed you can get on a commodity desktop in 6 months"... then sure.

People realized how stupid it was to waste money on mainframes when commodity hardware is moving so quickly.

Re:Skill Sets are disappearing (2, Insightful)

1c3mAn (532820) | about 5 years ago | (#27543013)

Why do people always think it is about speed. It isnt. Mainframes are not super computers. They dont really need to be able to have very high processing power, what makes mainframes great is their storage movement capabilities. 2 billion transactions a day is a LOT of data to be thrown around, and a mainframe can easily handle that.

Beowulf Cluster? Not so much.

Reliability and redundancy is unmatched in a mainframe. There is a reason why financial institutions run Mainframes. Because that data really cant be lost.

Mainframe was called Dead in the early 90s and companies tried to switch to open systems and FAILED miserably. 20 years later and most Fortune 1000 companies still use a Mainframe, because nothing comes close to what they do.

I've seen Cobol programs in my past job (1)

crazybit (918023) | about 5 years ago | (#27542533)

1. Cobol programs where written so bad and confusing that probably only the original programmer (he was the original maintainer) was able to maintain it.

2. The company was grabbed by the balls by the provider, who - along with the maintainer -, kept on saying "we can't assure that if you migrate this all will work fine".

and, since it was a "critical" application, we never migrated it. Managers never minded that in a demo I showed them the response with PostgreSQL was about 8 times faster.

that is what cobol was and is good for, grabbing a company by the balls and make it pay money to a provider for eternity. It's like having your main software written in obfuscated perl.

Re:I've seen Cobol programs in my past job (0)

Anonymous Coward | about 5 years ago | (#27542723)

It's like having your main software written in obfuscated perl.

So in other words, it's like having your main software written in perl.

Why replace? (2, Insightful)

Jane Q. Public (1010737) | about 5 years ago | (#27542589)

Hmmm. I suppose it could be that between the times that COBOL was developed (Grace Murray Hopper, FTW), and today...

There is more to a language than just being Turing-complete. There is syntax and geneeral usability, for example.

I know that there are still jobs out there for COBOL programmers. And it makes me sad.

books? (2, Insightful)

innocent_white_lamb (151825) | about 5 years ago | (#27542753)

Most COBOL books and tutorials are unavailable, out-of-print, or just plain gone.
 
What resources still exist for someone who wants to learn COBOL?
 
http://www.opencobol.org can easily be installed on Fedora Linux (for example) with a simple "yum install open-cobol", but what comes next?

Does this add up? (4, Insightful)

Allicorn (175921) | about 5 years ago | (#27542787)

How does this add up?

1. Around a third of UK companies say they have even at least one COBOL program somewhere in their enterprise.

2. Around three quarters of all UK electronic business is coded in COBOL.

I'm aware that there are allegedly pockets of COBOL here and there with some fairly significant nuclei of usage within certain business sectors but seriously... 80% of all electronic transactions?

Monster.co.uk search for single keyword in title, 11th Apr 2009:

Java: 173 hits
C++: 142 hits
PHP: 95 hits
Perl: 39 hits
COBOL: 1 hit

This doesn't seem to suggest a great demand for COBOL coders at present which - one would think - suggests little use of COBOL.

I've heard this "the world secretly runs on COBOL" story countless times over my career, but seldom seen more than a few lines of COBOL actually deployed in businesses I've worked with. Is the whole thing just a weird industry myth?

Re:Does this add up? (0, Troll)

meyekul (1204876) | about 5 years ago | (#27542919)

Its like your grandfather. Everyone knows he's too old and can't keep up with the kids anymore, but you don't want to say it to his face right? We're just waiting for the last COBOL programmer to die off and then then everyone will breath a remorseful sigh of relief and start coding in Java again.

Re:Does this add up? (4, Interesting)

PPH (736903) | about 5 years ago | (#27542991)

You are confusing the amount of development done with Cobol and the number of transactions handled by Cobol systems.

In my experience, the reason that Cobol still hangs on is that management continues to pursue the philosophy of "patch it just one more time" rather than "port it to something more easily maintained". As time goes by and continual patching gets more difficult, expensive and riskier, the amount of development goes down. But the systems are still up and running.

The ultimate in unmaintained systems was one at an outfit I used to work for where they lost the source code. Its gone, never to be modified again. It was lost before the end of the last century and was suspected not to be Y2K compliant. The solution was to write and run a routine on the applicable database to bump all of the date fields back (20 years, I think). Then, another small routine was written to post process the output add the time back. Management is grinning from ear to ear because, unlike all the other apps that cost millions to maintain, this one costs them nothing. As long as those responsible retire before 2020, that is.

None of you guys are getting it. (5, Insightful)

slashdot_commentator (444053) | about 5 years ago | (#27542791)

Its not just the mythical "mission critical" aspect that keeps businesses dependent on COBOL. MANY of those programs required either financial analysts to "vet" the COBOL program, or lawyers to "vet" the COBOL program complied with laws (privacy, methods of determinations, etc.).

Not just are you putting in the cost to refactor the program from scratch, not just are you risking a bug costing your company hundreds of millions to billions of dollars, but you also have to take in the costs of expensive NON-programmers to "bless" the new program.

Then also realize that the new whizbang technologies like SQL and java will RUN LIKE A DOG compared to the COBOL program. That's because mainframes are optimized data I/O machines. They're not great for making intense calculations or retrieving indexed relationships, but they are a BEAST when it comes to pulling out gigabytes of user data, and then making simple calculations and updates to each. It also sounds like top notch COBOL programmers programmed to the machine for efficiency. That's not really done anymore by generic programmers.

New shops don't have to consider COBOL. But any large company (and gov't) could potentially take a huge hit on their finances (in legal issues) if refactor project has a bug. You can roll the dice, or you can just pay another couple million/year and hope nothing ever forces you to consider replacing your legacy COBOL programs that no one knows how they work, or how to change them.

Per hr: cobol $120, everything else $30 (1)

LymeM (1314985) | about 5 years ago | (#27542849)

As someone managing a number of legacy mainframe/cobol systems (we do pl/1 too), the biggest reasons to move away from them break down like this: #1: Cost - Mainframe hardware is expensive, support is expensive, keeping or contracting programmers are expensive. #2: Availability - Finding a competent cobol programmer is much more difficult than it used to be, while you throw a rock and you'll hit 20 perl/java programmers. #3: Maintenance - Programs that have been written 30 years ago, and have been updated year after year, mostly poor documentation are hard to keep going, and require more person effort to do so. #4: Flexibility - Out business has been changing over the last 30 years, how can one expect something written that long ago to continue to last the tide. It may be working now, but when that next important change comes down, it may take significantly longer to respond.

The older generation isn't always wrong! (5, Insightful)

ErichTheRed (39327) | about 5 years ago | (#27542887)

I've had an interesting run through IT environments so far. Each one of my employers has successfully used what would be called a "legacy system" to do core business transactions. I'm not old by any means, but I definitely see no reason to get rid of systems that are performing well.

The qualification for that statement, of course, is "performing well." The side effect to using older systems is all the bolt-ons you have to use to get newer functionality working. My current employer uses a midrange system from the early 80s to run the core of the operation, and it has tons of extra software and hardware riding on top of it to do modern things like access without terminal emulators and message queuing. The time to consider a replacement is when these systems become too unwieldy or brittle to manage. For example, if a transaction-processing system needs a daily FTP feed from some source, and it doesn't get it, will that blow up the whole system? If the answer is yes, it's time to fix the problem or replace the underlying system if it's bad enough.

I'm very skeptical of anyone who comes in and says, barely looking at the existing system, that it needs to be ripped and replaced. A lot of it stems from the fact that IT hasn't matured all the way yet. People still come into the field knowing little more than the Java they were taught in school, and don't have the big-picture attitude you need to really understand IT. You may think I'm an old fart, but I'm really not. I've learned the basic rule of IT -- you're not there to play with computers and have fun. You're there to make sure the business you support is able to do their work, preferably without calling you in every night to fix something.

Another reason... (2, Interesting)

Cynonamous Anoward (994767) | about 5 years ago | (#27542907)

Why would you want to replace 2 billion lines of working COBOL code?

Easy...COBOL, while still in use and working well now, is not a language which is still growing...it is shrinking. Nobody would choose COBOL for a new project. The only jobs left for COBOL programming are maintenance. That means that there are no "exciting" COBOL jobs, and that only coders who learned COBOL, not engineers who are good at design or interested in building/maintaining good design.

"So it's old and all you can get is people willing to maintain, not engineer, the COBOL universe. so what?"

Well, what's what is that:

a) over time, code maintained by "coders" rather than "engineers" i.e. those who are simply proficient in a language, rather those with true engineering talent, will degrade. I have worked with both. I notice a trend. Those with engineering talent...a knack for understanding large systems at a high level and seeing bigger pictures, tend to improve the cleanliness, stability, and re-usability of existing code as they fix or extend it, because they look at the big picture and try to make a change such that it works well in the whole system. "Coders" tend to find the location where the logic goes wrong, and make the most obvious spot adjustment to make the problem go away. Even extensions are treated similarly. Hence, with mostly these types of engineers working on COBOL code, those systems are going to degrade over time. This effect can happen rapidly...I've seen it happen to code that was less than 5 years old. The fact that COBOL code still works is probably more a side effect that all coders of that generation had some engineering skills beaten into them. The younger generation with their "learn a language and get paid" mentality will bring that code to it's knees in a decade or less.

(a) implies problem #2:

b) With code which will degrade as younger, less "design" oriented maintainers are forced to take it over, maintenance becomes a primary concern. Yet as the language gets older, and the code ages and begins to break, gaining more of a reputation for being in shambles, there will be less interest in working on it. Meaning that each generation will produce fewer and fewer COBOL programmers, an effect we are already seeing.

Businesses will be content to sit back and look at their well working, low cost maintenance systems, and think that things will always be that way as long as the don't ask anything new of the system that will cause it to need replacing. This is NOT the case. Eventually COBOL programmers will be all but gone, and those that remain will come at a high premium, and there will not be enough for everybody. At that point, the code will start to break, with nobody to maintain it.

This is when businesses will freak out and think "we need to replace this COBOL program with something in a modern language that we can find programmers for." Except that these old systems are probably not well documented at an algorithm level. The best document is, well, the code. So what they will need is simply someone willing to read through the old code and duplicate it's behavior in a more modern program. Well that doesn't sound SO hard..except, wait, what? You mean, in order to port a program away from COBOL, you need an engineer who still _understands_ COBOL? oh, crap...

How to learn COBOL? (1)

drolli (522659) | about 5 years ago | (#27542949)

I am a physicist but i think about switching the job to softrware development. COBOL is one of the languages i consider to learn for a living (i wrote productive applications in pascal,basic,c,assembler,perl,python.lisp,tcl,java,javascript,tcl,matlab,shell languages). Any comments how to start from this starting point?

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...