Slashdot Mirror
Don't Count Cobol Out
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."
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 essays.
(I wonder if ""Considered Harmful" Considered Harmful" Considered Harmful is soon to follow? Oh wait. That already happened 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.
Javascript + Nintendo DSi = DSiCade
I'm gonna go ahead and count COBOL out. Don't be silly.
Prediction: The real iPhone killer is going to be sex robots from Japan. Think about it.
Long Live the Lords of COBOL.
Oh, say does that Star-Spangled Banner entwine / The myrtle of Venus with Bacchus's vine?
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.
Prediction: The real iPhone killer is going to be sex robots from Japan. Think about it.
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).
putting the 'B' in LGBTQ+
My University (Texas A&M Kingsville) still requires COBOL for every IT-related degree, even those not oriented towards programming. My jaw almost hit the ground when I found out that I was going to have to take a COBOL class to earn my CIS degree. Although there is obviously still a need for people to support applications written in that archaic language, I really wish that the bureaucracies of the world would let it die already.
the use of Cobol cripples the mind; its teaching should, therefore, be regarded as a criminal offense
I thought it was BASIC and not Cobol in that sentence.
DNA in your Linux: DNALinux
As a younger person in the world of IT, I question how much longer things like COBOL survive. My theory is that with the aging Baby Boomer population, those IT managers will soon head off to retirement. Younger folks will look at that COBOL as something that needs to go and with Bob gone, we can slowly bring that system to the 21th century.
As an aside, /. had this little quote at the bottom of the page when reading TFS: "senility, n.: The state of mind of elderly persons with whom one happens to disagree." I thought it was fitting.
Roughly half my comments are never submitted. You may be reading the better half...
Gov. Schwarzenegger ordered a cut in pay to California state workers, and was told that it would be impossible to implement because the payroll system is in Cobol and nobody can touch it.
Sounded like political bull to me, but then again...
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.
Rome taught me patience and assiduous application to detail. Virtues which temper the boldness of great, general views.
000100 IDENTIFICATION DIVISION.
000200 PROGRAM-ID. HELLOWORLD.
000300
000400*
000500 ENVIRONMENT DIVISION.
000600 CONFIGURATION SECTION.
000700 SOURCE-COMPUTER. RM-COBOL.
000800 OBJECT-COMPUTER. RM-COBOL.
000900
001000 DATA DIVISION.
001100 FILE SECTION.
001200
100000 PROCEDURE DIVISION.
100100
100200 MAIN-LOGIC SECTION.
100300 BEGIN.
100400 DISPLAY " " LINE 1 POSITION 1 ERASE EOS.
100500 DISPLAY "NO THANKS!" LINE 15 POSITION 10.
100600 STOP RUN.
100700 MAIN-LOGIC-EXIT.
100800 EXIT.
Are you wading the waters to determine how palletable COBOL would be in your buzzword soup? Web 2.0 COBOL cloud computing does have a ring to it. Old is the new "new".
they're going to be telling us that Fortran is the new Java.
Censorship is obscene. Patriotism is bigotry. Faith is a vice. Slashdot 2.0 sucks.
What do COBOL coders make these days? Is it worth learning?
Can someone give me a side-by-side example of C and Cobol program or statement to do the same thing which would illustrate why Cobol is so "evil"?
While there may possibly exist some implementation of the summary's mentioned "XML/metadata, Web Services, Service Oriented Architecture" in COBOL, I wouldn't consider it a key element to these technologies. It may be that perhaps many new technologies are required to work with existing mainframes running a whole mess of COBOL code, but COBOL itself is not a key contributing factor to the success of these technologies. If anything, a good implementation should use abstraction to make legacy technologies irrelevant and compatible with newer technologies.
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.
An Eye for an Eye will make the whole world blind - Gandhi
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.
The report neglected to mention that 239.9 billion of those lines were boilerplate headers and math operators spelled out with English verbs.
Quote: http://www.informatik.uni-freiburg.de/data/citations/citation.2007-06-26.0532689966/view?set_language=en
Dijkstra said this about BASIC though: "It is practically impossible to teach good programming style to students that have had prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration."
Honestly, I can only think of three words in reply to that. WTF?
We're not talking about the stylistics of Ancient Egyptian art or the evolution of the galaxy. In 11 years the landscape of the programming language world can change entirely. And since 1997 it has done so. This is absolutely the number one worst ever post on slashdot. Trying to tell us that we might be learning Cobol next is like going to a paleontology conference and telling everyone that they're going to have to study the Bible next. The only thing it does is make you look ignorant.
It's really cool if you remove the 'b'.
Noooooooooooooooooooooooooooooooooooooo!!!!!
What I got when I tried to post the original:
Filter error: Don't use so many caps. It's like YELLING.
So what do you do when yelling is appropriate?
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
...IT management paid for this.
"Oh please. Recruit us another few thousand COBOL programmers so we can patch this application just one more time."
OK, so COBOL isn't the worst language possible. But given a clean slate, how many new applications would be written in COBOL?
Anybody? (sound of crickets)
I'm wondering whether recruiting CS majors for COBOL jobs is as successful as recruiting high school grads to do military service in Afghanistan is.
Have gnu, will travel.
This is one of the prime examples of why measuring code by "lines" is bogus.
After all, in the typical Cobol program, most of the variable names are so long that you can't fit two of them onto a line on your typical cubicle worker's screen. Of course there are zillions of lines of Cobol code. And all those zillions could probably be expressed in perl or python in maybe 100 lines, or 1000 lines of C. (But you wouldn't be able to read them.)
Now if /. only had a HHOS moderation ...
Those who do study history are doomed to stand helplessly by while everyone else repeats it.
"billions of lines of new Cobol code are being written every year"
that accounts two hello worlds, and one program that shows the first 1000 fibonacci numbers.
factor 966971: 966971
oh lord o cobol, hear my prayer.
or else!
Like the phone book? (think "more cowBELL") Produced with COBOL. COBOL can used to make a VERY fast PostScript engine. Single process, 100 pages in about 1 minutes, with pulling high resolution image blobs from Oracle.
May I please have my frontal lobotomy if I bring back the ashtrays?
"COBOL actually aint so bad
repeat until believe
(the above was much more droll in my
original, authentic all-caps cobol-esque
version, but the higher powers have deemed
that you cannot enter caps cobol syntax into
a slashdot post.)
Where are we going and why are we in a handbasket?
That, that uh, accountants and lawyers
are in cahoots with the Devil
Yeah, they're in cahoots with the Devil!
To cover the Earth
Cover the Earth with this wretched swill
of gutless, mediocre, middle-of-the-road,
sleep-inducing, homogenized pabulum programming languages for the slavery of daily drudgery
Sometimes I get that feeling man, but I know it's a lie
I know it's not true
I know it's not true
And I'm talkin' to Larry Wall now
Larry Wall, I'm talkin' to ya
Larry Wall, where are ya?
Gotta have more Perl!
Gotta have more Perl!
(with respects to Mojo Nixon)
Dog is my co-pilot.
<joke> ...
As all banks (and the USA) are very close to bankruptcy, and that Cobol is mainly used in heavy banking apps, no more Cobol programs should be running at the end of 2008.
Arg, oops. Someone just said me that Pdt Bush decided today that the US government will help banks... Some Cobol programs will also see the year 2009.
</joke>
In fact... I think that remaing Cobol programms will still run when the last Java powered device will be trashed (or recycled).
Cobol apps in my company ALWAYS works.
To obtain a 99,999 availability with 'modern' technologies, you need ... [Put there all arguments that can show that *<Cobol+Mainframes]
So, Tumbleweed wakes up after almost 8000 years in suspended animation. An official in the year 9999 says, "Having searched the ancient archives of Slashdot, we see that you appear to have a working knowledge of COBOL. We have this Y10K problem coming up and we were wondering if you could possibly give us a hand with it."
Have gnu, will travel.
I've been in the financial industry since '81. In this sector there's still a ton of COBOL out there. And, in fact, sometimes it makes sense to expand on the old COBOL CICS code and VSAM rather than build something that takes java ESB, an SQL database, JSP, hand-written HTLM, javascript, unix scripts, autosys, FTP and a bunch of other cludged-up technologies.
Don't get me wrong - I like the new stuff because it makes me marketable and is so complex the users have no choice but to bow down at my feet.
I'm just sayin'....
where I learned COBOL in the early eighties was just ahead of the curve?
And that punch card thing was so retro it was cool, I guess.
A few years ago in college, one of my professors was giving away a table full of programming/comp sci books. I stumbled on 'Basic COBOL' or something like that and joked "You can probably just throw this one out." He laughed and said it was the most widely used language on the planet. At the time I didn't really believe it, but kept it anyway, I'll have to crack it open and take a peek.
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.
Ooooh, Cobol must be popular if there are billions of lines of new code written every year!!! But seriously, the amount of lines of code doesn't mean Cobol is making a comeback. It could be a few companies that write/publish the majority of the billions of lines of code. What I would like see is the amount of code written for every programming language and juxtapose them against Cobol, then we'd get the bigger picture.
Also, I'm sure somebody could fit 240 billion lines of cobol into one line of perl... one reaaallly long line of perl ^_^
#include "stdio.h"
#define e 3
#define g (e/e)
#define h ((g+e)/2)
#define f (e-g-h)
#define j (e*e-g)
#define k (j-h)
#define l(x) tab2[x]/h
#define m(n,a) ((n&(a))==(a))
long tab1[]={ 989L,5L,26L,0L,88319L,123L,0L,9367L };
int tab2[]={ 4,6,10,14,22,26,34,38,46,58,62,74,82,86 };
main(m1,s) char *s; {
int a,b,c,d,o[k],n=(int)s;
if(m1==1){ char b[2*j+f-g]; main(l(h+e)+h+e,b); printf(b); }
else switch(m1-=h){
case f:
a=(b=(c=(d=g)g)'g)g;
return(m(n,a|c)|m(n,b)|m(n,a|d)|m(n,c|d));
case h:
for(a=f;a=e)for(b=gg;bn;++b)o[b]=o[b-h]+o[b-g]+c;
return(o[b-g]%n+k-h);
default:
if(m1-=e) main(m1-g+e+h,s+g); else *(s+g)=f;
for(*s=a=f;ae;) *s=(*se)|main(h+a++,(char *)m1);
}
}
The Kruger Dunning explains most post on
Now: allow me to rant on all of you who call it the "Patriot Act". ARGGGGGHHH!!
(There: got my pirate cred in there, too.)
Comparing the "millions" of lines of cobol appls with most languages is not fair. Most of those "millions" are devoted to things that on most current systems are regarded as "configuration" or "rules" or "auxiliar data files". Nobody talks about the "millions" of machine code lines that represent the compiled code, for example.
Despite that, I agree that Cobol is maybe the most used P.L. in business.
I'm still not putting it back on my resume. Not no how, not no way.
Why bother
Trying out a script in Expect.
Delightful.
You see where tidier tools have stolen market share from TCL.
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
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).
It is called ADD ONE TO COBOL
You will be assimilated & spend the rest of your life in Bangalore implementing crazy Java standards written by MBA's during their Colorado ski trips who have no idea what they're doing.
In the cafeteria at Southern New England Telephone, we would regularly encounter stuff best described as FILLER PIC X VALUE LOW-VALUES.
Your return stack and everything came out of those 128 bytes ...
No screen RAM either. You had to update the image with the CPU as the screen scanned.
No sig today...
I don't know anyone who codes COBOL, I don't know anyone who knows anyone who codes COBOL. Same for NASCAR, but I know they are out there.
I think a long time ago, some Oracle Apps were written in COBOL.
I learned COBOL at college when I was training to be a Systems Analyst, the idea behind COBOL was that it was supposed to be a language that management types could read. I promptly tried to forget it as soon as I could because it was a particularly painful language to work with.
I would never touch it again, but I appreciate that if it is not broke don't fix it, the question is when does it become broken enough that retro fitting features becomes a problem ?
We are working to replace a VAX system running VMS with a more modern machine running some linux variant because it is becoming to difficult to support, but it has served us well for twenty odd years. The main problem is recreating the system that is essentially kludged, many who worked on it initially have long since retired.
Old languages become harder and harder to support though, FORTRAN has survived long after it should have died, but it is still well known in scientific circles, however it becomes harder and harder to support in modern systems even with things like GOMP support.
Cobol's collaborative development (a.k.a Commitee) model makes it the best choice for Intelligent Design in programming and Society re: the acknowledgably Flat, Hollow Earth. The only sane option, really.
And what's wrong with spaghetti code, I do inquire? With all the hunger and food shortage in the world, how can people be possibly against anything so satisfying?
Not only that, but it forces developers to work together in great numbers, at all stages : design, development, and (mainly) maintenance. If you want to reduce violence in the world, give the people something to do! Employ them as cobol coders! Let the only wars be flame wars between them and VB/NET/PERL/JAVA/.... and other coders.
Yea! The world needs more cobol, not less!
Make it universally mandatory! Who's going to have the time or inclination for sniping, rock-throwing or bombing, etc., if they're too busy urgently coding cobol!
To the 80-column editors with them all! That's what I say! Look at me! 10-12 hours a day of cobol for 10 years didn't hurt me none. Builds up your moral fibre, it does. Heck. We were _glad_ for a chance to code in cobol.
To the cobol-camps with them! ;-P
I've programmed in COBOL (I was young and needed the money). It is the most programmer unfriendly language (except for RPG) I've ever used. It has a large installed base which means it will be around for a while. But that doesn't make it a good thing. I've thought about starting a society to discourage its use.
Coder's Stone: The programming language quick ref for iPad
Are they teaching "add 1 to COBOL" in the universities, then?
Well, apparently, you only have to fool the majority of people for a little while.
Comment removed based on user account deletion
there will still be COBOL.
MOVE A TO B.
COMPUTE GROSS-PAY = HOURS-WORKED * HOURLY-RATE
SET MY-INDEX TO 1
SET ADDRESS OF MY-LINKAGE-SECTION-ITEM TO MY-POINTER
READ TRANSACTION-FILE INTO TRANSACTION-RECORD-WS
MOVE 2101 to AD
BEGIN WAR
SET CAPTAIN = "What happen?"
SET MECHANIC = "We get signal"
SET CAPTAIN = "What?"
OPERATOR MAINSCREEN = TURN-ON
SET CAPTAIN = "It's you!"
SET CATS = "How are you gentlemen?"
SET ALLYOURBASE = BELONGTOUS
SET YOU = AREONTHEWAYTODESCTURCTION
SET CHANCE != SURVIVE
SET LAUGH = "Ha ha ha ha"
OPERATOR CAPTAIN = "!!*"
SET CAPTAIN = "Take off every Zig"
MOVE ZIG FOR GREAT-JUSTICE
Remember, Slashdot does not have a -1 disagree moderation, and no, troll, flamebait, and overrated are not substitutes.
The guys that are always saying COBOL is dead or dying are the same IT newbies that you can randomly question at trade shows as to what a "mainframe" is and they invariably reply "some computers from the 1960's". COBOL is alive and well lads, and mainframes are enjoying a healthy growth in install base. Get out of your Mom's basement and check out the datacenters of Fortune 500 companies. That's a room where people get paid for working with computers and data. No shag carpet or wood paneling. ;)
Officially a geek since 1984
"A computer without COBOL and FORTRAN is like a piece of chocolate cake without ketchup or mustard." -- John Krueger
Slashdot's first reaction to VMware
I once learned COBOL, and programmed it exclusively for 54 weeks before moving on to jobs outside of the typical business shop. I'm wondering now if the next big thing will be COBOL-script?
"It's the height of ridiculousness to say for those 9 lines you get hundreds of millions."
As a long ago reformed COBOL programmer, I know that there is NOTHING you can do in COBOL that you can't do faster and in a more easily maintained manner in an object-oriented language. If the legacy platform only supports COBOL, then you are still better off changing platforms. The stuff that hasn't changed still exists because it is managed by a bunch of cowards who are only interested in punching the clock until retirement.
...in a no-nonsense, http://codex.cs.yale.edu/avi/os-book/os6j/online-dir/Java-primer.pdf kind of way for its modern incarnations? Though arguably its code is more readable than Perl's ;-) in the first place...
The developers of COBOL (Grace Hopper among them), expected COBOL to last a maximum of 6 months, before something (damn near anything) better came along. They admitted even 1 year after first writing it, that if they had known it would have lasted 1 year, they would have (admitting they could have) done a better job. Having learned COBOL and thus suffered, I agree that the year slated for COBOLS death was in the last millenia, and prodding the living dead on is wrong, wrong, wrong. I had a prof. in CS who actually tried to put a few virtues to COBOL, but admitted it was mostly a sukky language. It had a few features C didn't have, but people quickly expressed that the features could be quickly and easily written and used as a library. Coding in any other language is much less verbose, infinitely less arcane, and likely to execute on given hardware much more quickly.
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
Officially: "No comments"
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.
You must come from the crappy-COBOL-on-PCs world. In Wang mainframes code space is "pure," meaning that nothing can be written into code space except by the OS when loading a program into memory. Wang mainframes are also stack-based. But COBOL was not specified to be recursive.
Look at the bright side: there's always seppuku.
Yeah, damn modern programmers always planning ahead and detecting serious flaws, brining the whole system down if needed when something unrecoverable happens. When there's a problem that means all your data is worthless, systems should just stay up and keep right on outputting those worthless numbers! Five years later, when somebody notices, you can apply a patch that makes no sense to anyone and isn't actually accurate ("better than nothing, right?")
See: http://firasd.org/weblog/2008/05/07/dilbert-average
-- 'The' Lord and Master Bitman On High, Master Of All
i am 20 something... i code in cobol for a bank... its their core banking solution... a microsoft system that was to integrate with the Mainframe was unable to handle the speed with which data was posted to it...(the mainframe is 39 years old, surpring a new language on a new platform couldn'thandle it LOL... an earlier attempt to migrate the system to java failed when the new application was twice as slow with only a portion of logic .. ) we are short on good cobol developers... thankgod we have a team of folks from india who are now busy coding in cobol and earning big bucks... yes cobol is old ... yes it is museum material but it does the job and combine it with mainframes ... the speed and reliability is unmatchable...
Merril Lynch reports that 70 percent of its business runs on Cobol apps.
That explains a lot.
So what? Fortran originally didn't support recursion either. Recursion is usually avoided in high performance, real-time, and fault tolerant systems, anyways. It is difficult or impossible to bound.
Programming languages are tools used to solve problems. Any decent programmer will have more than one tool in their toolbox. Some tools are appropriate for > 1 problem space; there is overlap.
/var/log then you're probably trying to use it in the wrong problem space.
The problem space for COBOL is usually confined to, you know, implementing business rules.
If your problem with COBOL is that you're having trouble using it to process
Truly unfortunate are all the comments modded as informative that are anything but. Even more unfortunate is I've come to expect that of slashdot.
LOLCODE is rapidly gaining popularity. It's at least as readable as COBOL and very popular among programmers. At the same time integration and migration is very business friendly. While there has been a lot of press about the Y2K bug affecting large-scale COBOL installations, you will hardly find any news concerning Y2K issues in LOLCODE. In 2003 Gartner group predicted that most business transactions will be done in LOLCODE by the end of the decade.
I'm a former mainframe cobol programmer, I've been writing VB windows applications for the last 10 years.
I always tell people, the next time you swipe your debit/credit card to buy something there are millions of lines of cobol code making that possible, from the authentication code you immediately get back to the monthly bill you'll receive in 30 days. Mainframe Cobol is rock-solid-stable, damned reliable and in the long run, much cheaper than any large VB application I've ever seen.
Lots of Banks have a Mainframe based system with COBOL as their primary language.[This was the only safe and sound language available at the time]. It's not just the banks, lots of Pharma/healthcare, Retail businesses(e.g. Tesco) , insurance companies manufacturing companies have years of data on a mainframe. They run on applications that are age old(20 to 30 years or older). These systems have been developed, modified, enhanced and messed with over years. We call such systems are organically developed systems and they have absolutely no documentation and are supported by a workforce that is nearing retirement age. these guys are the System experts. Now you might think that as the main workforce is retiring the systems too should retire and the applications will move on to newer platforms. Now this where the Indian work force comes in. The likes of Infosys, Wipro, Satyam and TCS have a huge workforce of people trained in COBOL and mainframes. These guys are now working with the retiring workforce and getting all the system knowledge. It is hopeless work and requires lots of sleepless nights but the money is good and indians will do it cheaper. The bank gets a huge number of contractors working in their IT dept and are happy. This workforce may not provide the same quality of work provided by the earlier experts but they'll get the job done. Coming to the issue of migrating the existing applications onto the newer platforms. Imagine a bank that has hundreds of branches across the country. They have people working for them and are trained in the current setup. The banks have been developing systems to plugin [lots of internet banking software still talk to a Mainframe back end via CICS transactions(In IBM, UNISYS, FUJITSU etc. may have a different thing )] to their core mainframe. The cost and effort of replacing the core mainframe logic as well as the interfaces to all the systems with a new platform is just too huge. No CEO would take the risk. Instead what they are now trying to do is open all new business on the newer systems and continue with the older systems. From where i see COBOL still has a long way to go. I am not going to shun a COBOL job simply because i do not like the language. Once you get into the business and know the institution you are working for well enough it is the domain knowledge that will get you up and not your programming skills. Programming skills come really cheap these days. India, china etc.. and even these are now facing competition from other countries where the cost of living is even lower. Yes COBOL is a language of the past but it is still going strong and will remain so for a long time.
This pretty much blows my mind:
http://www.sorn.net/media/photos/blog/cobol-gtk-sharp.png
The compiler here is called Wildcat, and it's a .NET compiler (runs on the CLR).
Your a telling me. I helped port the jpeg library {...} to DOS.
I must say "thank you". The product of your work was very helpful to me when I was a kid.
Borland's c compiler wasn't that bad for dealing with memory with the huge modifier that abstracted most of the details.
The fond memories... I learned to program thanks to Turbo-C and later Borland-C. (And learned also to work around the bugs of the "bcc" optimizer...)
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
Billions of lines of COBOL code a year - let's see, if the same functionality were written in a modern language, what would it be? Half a million lines a year?
If a line of C[++] was a dollar, a line of COBOL would be an Italian Lire. And just as obsolete.
The older generations in Europe also still think of values in their old Franks, Lires and Marks, but that doesn't make those currencies "current".
I tagged this with the only thing I remember from learning COBOL :
DISPLAY SPACES UPON CRT WITH BLANK SCREEN.
which is quite a mouthful compared to the previous clrscr() I was used to! :P It makes a cute tag, too : displayspacesuponcrtwithblankscreen.
"I remember Y1K, every abacus had to get another bead"
We are a fortune 10 shop. We still do most stuff in COBOL. Recent numbers I saw would have us at 50,000+ packages Assuming duplicates, that is about 20,000 plus COBOL programs, just counting the stuff that accesses DB2, with more being created every day.
So, the count is there, and there ar emore shops then you guys care to admit.
COBOL will last until I retire, and probably after that.
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!
Real programmers remove recursion while working with an imperative language on a 704.
77 MADNESS Computational-NUT PICTURE IS "INSANE" VaLUE "NOTHING".
.
OOPS! Filter error: Don't use so many caps. It's like YELLING.
(Sorry Admiral Hopper! But, I'm sure you'd agree with me)
.
- Aaron A. -
Bringing Pinoqachole to the natives since 1643.
And fair enough too. I write a lot of firmware, and restrict myself to a compiler subset for all those reasons (eg being wary of using the heap). But that doesn't mean I want the language to force those inelegant restrictions.
You can't make real money with it. Within its problem domain (Plain Old Necessary Business Stuff - accounting, payroll, customer records, etc.) it just works.
But with the wonderful New Age technologies, one has almost infinite possibilities for fun and profit: Consulting, teaching, text books, instructional courses, tools, "15 minutes of fame for inventing the next framework that shores up some flimsy new technology", security consulting, criminal opportunities (hacking those mainframes that run that old COBOL just isn't very practical, much better now), conventions, and definitely more groupies. Those old COBOLler's really should wise up...they can take some obsure COBOL function, discover it as a breathtakingly new concept, and make their fortune marketing it. (One example that comes to mind is AOP versus the COBOL copybook..problem with the COBOL copybook is that it's very flexible and can be pretty much mastered in 1/2 hour, unlike the possibilities offered by AOP.) (Another point might be "reuse"..a full COBOL ecology in a large shop might have thousands of components getting reused millions of times per day - a real disadvantage in that it doesn't take genuises or all kinds of add-on products or consulting to make it work.)
In summary, COBOL's problem is that it is not a real MOP language. (Money-Oriented Programming)
Used to call them cobolans some 30 years ago.
So what if there ever will be 40 billion lines of Cobol code. If there are no jobs in COBOL then this means nothing if you are looking for a career.
COBOL is/was (whatever) a great language but the fact is there are no jobs and I doubt there ever will be.
And COBOL does cripple the mind. The language construct differs and its experience cannot easy to transfer to modern better (hence the demand for jobs in COBOL) languages.
There are so many bridge's built decades ago and new ones built everyday but that doesn't mean you have to replace them or even more to the point use the same old ways (materials, concepts) which were used.
Face it COBOL is dead from the prospects of any career in software development.
The Python version is a good example, but I would note to the REXX sample for the same purpose, short, clear and very elegant:
http://99-bottles-of-beer.net/language-rexx-493.html
I programmed Cobol up to 25 years, and until today, I learned some +25 diferent languages. These, almost 10-12 I've used for +10 years.
My opinion (IMHO) is: COBOL is a great language for batch processing, to larger data volumes and for calculations performance.
In the punched paper card era, coding by hand with a pencil in the program listing, and waiting hours to some cards being punched and processed, was a kind boring to do anything in ANY language.
Today, we have graphical interfaces, say "real time editors", witch are hundreds of times faster to work.
So, IMHO, I see no trouble in writing some lines of code as this appears to be very fast and easy. I'm not lazy to that.
And NO, I don't like to expend hours programming.
I think computers must do all the work, so I code hardly to do better software, for human use. I work harder for a time, then I have a high performance program and if possible, with an elegant solution, easy-to-use.
This is a personal approach of my job.
I lack some COBOL features very often, mainly, the possibility of control memory use and the short object code, very suitable for performance optimization.
And more than all, I think there's no one language for all thinks. I trust about mixing languages, using what is better for in case. In the 80's, I developed software for CICS, mixing COBOL, CSP/AD (a IBM L4G), Assembler, RPG II and REXX, all in the same system running under VM.
Then came to Clipper, VB, Access VBA, and many modern tools. They are very good for sure each one for each case.
Today I work with a legacy system done Unify-Accell (an older L4G) and Sybase Adaptative Enterpise Server for a larger retailer company.
The system is migrating to a new one, and some partes of the new main core are done with (guess...) COBOL!
(sorry bad english)
Information technology means all information.