Don't Count Cobol Out 274
Hugh Pickens writes "Although Turing Award-winning computer scientist Edsger Dijkstra once said, 'the use of Cobol cripples the mind; its teaching should, therefore, be regarded as a criminal offense,' Michael Swaine has an interesting entry to Dr. Dobb's Journal asserting that Cobol is the most widely used language in the 21st century, critical to some of the hottest areas of software development today, and may be the next language you'll be learning. In 1997, the Gartner Group estimated that there were 240 billion lines of Cobol code in active apps, and billions of lines of new Cobol code are being written every year. Cobol is a key element in the realization of modern distributed business software architecture concepts — XML/metadata, Web Services, Service Oriented Architecture — and e-business."
Another one? (Score:5, Insightful)
Dijkstra was not known for being conservative in his statements of opinion. His "GOTO considered harmful" essay did a lot of good, but it also did quite a bit of damage. To the point where we ended up with a variety of "considered Harmful" Considered Harmful [meyerweb.com] essays.
(I wonder if ""Considered Harmful" Considered Harmful" Considered Harmful is soon to follow? Oh wait. That already happened [purdue.edu] in '87.)
A more conservative viewing of COBOL would show that it held a useful place in history, but is now antiquated. You'd need to be extremely conservative to think that COBOL has a place for growth in the modern world.
Oh snap. We got another one.
Let's be realistic here.
1. 1997 was 11 years ago
2. Everyone was preparing for Y2K
3. Those billions of lines of code were often replacing billions of lines of coded that were removed
As someone who once worked with mainframes, I can tell you that COBOL isn't dead. However, it's not exactly thriving, either. Legacy systems do their jobs well, so there is little reason to replace them. Instead, many companies use technologies like Java->CICS connectors to bridge the gap between old and new. But that doesn't mean that anyone is going to be developing "millions of lines of COBOL".
Quite the opposite, in fact. Business moves more quickly today than in any period in history. And with business moving so quickly, companies find they need to develop new aspects to their businesses. Those new aspects often take the form of new opportunities to develop new software.
If anything, I think COBOL is still hanging on because the mindset for technology is still external facing. Remember the Dot Com Boom? Well, one of the side effects was that technology shifted from optimizing internal operations to interacting with customers directly. Which is not a bad thing, except that internal operations shouldn't be neglected. Thus I see a lot of companies with inefficient internal procedures because they have not invested in proper internal technology infrastructure. This has left a niche where old COBOL programs are nursed along despite a growing amount of manual work for employees at many companies.
Wouldn't it be nice if technology could solve their problems? Well, it can. All we need is someone to make the investment.
With the economy going bust at the moment, I have a feeling the pendulum is going to swing back the other way. Companies are going to need to tighten their belts and become more competitive on price. Which means that they need more efficient operations. With the massive advancements in technology and ensuring code quality in the last 10 years, I fully expect that companies will soon have systems every bit as solid as their COBOL mainframes. Except they will be designed with more rapid change and flexibility in mind.
Cobol defeated da Terminator (Score:5, Informative)
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 [sacbee.com] and nobody can touch it.
Sounded like political bull to me, but then again...
Re:Cobol defeated da Terminator (Score:5, Funny)
Re: (Score:2)
For real. Unfortunately, I couldn't find any links
Re: (Score:3, Informative)
Yup, maybe me laugh when I saw it because I was writing 6502 assembly at the time
http://en.wikipedia.org/wiki/MOS_Technology_6502#6502_in_popular_culture [wikipedia.org]
In the science fiction movie The Terminator (1984), starring Arnold Schwarzenegger, the audience at one point is treated to a view through the T-800 Model-101 robot character's eye/camera display with some 6502 assembly/machine code program fragments scrolling down the screen. The program was listing the Apple ][ Disk Operating System (DOS) 3.3 disassembled
Re:Cobol defeated da Terminator (Score:5, Informative)
000200 PROGRAM-ID. KILL-SARAH-CONNOR.
000300
000400*
000500 ENVIRONMENT DIVISION.
000600 CONFIGURATION SECTION.
000700 SOURCE-COMPUTER. SKYNET.
000800 OBJECT-COMPUTER. T-800.
000900
001000 DATA DIVISION.
001100 FILE SECTION.
001200
100000 PROCEDURE DIVISION.
100100
100200 MAIN-LOGIC SECTION.
100300 BEGIN.
100400 PERFORM UNTIL SarahConnorIsDead.
100500 FIND SARAH CONNOR.
100600 SHOOT SARAH CONNOR.
100700 END-PERFORM.
100800 MAIN-LOGIC-EXIT.
100900 EXIT.
Re:Cobol defeated da Terminator (Score:5, Interesting)
Dear younglings (or oldlings):
If you want a REAL challenge, forgot cobol. Try programming an Atari 2600 gaming console. You have just 128 bytes of RAM to create a playable video game. (No that was not a typo... 128 bytes.)
I tried it once.
I gave up.
It gave me new respect for the original Atari geniuses who created playable versions of Space Invaders, Missile Command, Cosmic Ark, and Jr. Pacman, and turned a cheap console into the #1 system of its day (1977-to-1984).
Re:Cobol defeated da Terminator (Score:4, Interesting)
The Atari 2600 isn't that hard. It may be limited, but the 6502 is actually a pretty developer friendly architecture. Modern debuggers like the one in Stella can make the process pretty straightforward. (Though I would never dispute the challenges posed by cycle counting in an effort to get better graphics out of the system!)
If you want a real challenge, try programming the IBM PC in assembler sometime. As in the original systems from the early 80's. It won't take you long to start swearing at the stupid memory segments with their stupid memory models all focused on stupid interrupt calls that are stupidly undocumented! GAH! To add insult to injury, try 80286 protected mode. (Hint: It never actually worked.) For even more fun, try dealing with EMS and XMS memory using a DOS compiler. Yay! How fun! How wonderful! How challenging! And not in a good way!
Stupid PC. It's amazing that we let it become the dominant platform. (Though in the defense of us geeks, a modern PC does look a LOT different than those beasts of yore.)
Re: (Score:2)
We (well at least my generation) didn't see the low memory or EMS or XMS as much of a handicap. Hell we saw it as an improvement!
I think its amusing that youngsters today can't grasp having to do something useful with such antiquated equipment...
Re:Cobol defeated da Terminator (Score:4, Interesting)
It was an improvement as our programs became more memory strapped. That didn't mean that they weren't a bear to program. Heck, they were a bear to use! No one remembers it anymore, but we used to have to create boot disks for nearly every game just to get all the necessary drivers loaded while simultaneously leaving enough low-mem to run the program. It actually got to the point where I was putting a boot disk in the box of each game I purchased.
DOS Extenders did eventually get good enough to where the game effectively loaded its own Operating System. After that, you didn't care how much low memory there was. But man, was getting there ever a pain!
Re: (Score:3, Interesting)
By the time of DOS 6, I found a different solution:
I set up a config.sys menu that set up the system the way I wanted it to run.
It had generic entries (XMS, EMS, Clean) and game-specific entries.
(It even had sub-menus and entries to go back to the main menu)
You could even pick up the current Config.sys mode in your autoexec.bat and automatically start a game!
Re: (Score:2)
There may have only been 128 bytes of RAM, but the game itself was stored in ROM. The RAM was used to store temporary variables (player scores, player positions, player state, game level, game mode). It would take more than 128 bytes to write something like the sprite tank battle game in the Combat cartridge. You would need 64 bytes to store the bitmaps for each tank orientation (8 directions x 8x8 bit sprite = 64 bytes).
The most amazing cartridge was Atari 800 Basic which attempted to implement the Basic p
Re: (Score:3, Interesting)
I believe mikael intends to refer to Atari 2600 BASIC [atariage.com]. It was limited to 9 characters per line and that only worked because it flickered like mad. Crazy, crazy idea. The 2600 simply didn't have enough hardware to generate a text display, even if we assume that cartridges could use superchips for an extra 128 bytes of memory. 2 sprites per scanline just isn't much to work with.
The Atari 800 was a much more sophisticated piece of hardware with support for many mor
Re: (Score:2)
Yes, that's the one - I still remember the day I went into town with my parents to buy the cartridge and reading the manuals while taking the bus home. There were labels that were placed on top of the keypads to show which button did which. Like a ZX Spectrum, each key had at least three different color coded functions.
The Atari 800 was definitely much nicer - plus the two bonus secret graphics modes which supported four color characters although these were only 4x8 pixels in size.
Re: (Score:2)
Re:Cobol defeated da Terminator (Score:5, Informative)
The 2600 only has TWO sprites. The missiles and the ball are 1-bit graphics and thus aren't really counted as "sprites". So there are 5 movable objects. Then there's the playfield. The playfield plots rather long lines (4 pixels per bit IIRC?) at fixed locations. Of course, there wasn't enough memory to store an extra 20 bits to fill the screen. That would be too easy. Instead, the [i]same bits[/i] were reused to draw the second half of the scanline. You could have the playfield repeat or you could have it mirror the bits. But if you wanted to actually have a full-width playfield, you had to "race the beam".
And by "race the beam" I mean that you would time the processor cycles just right so that you would replace the bits in the registers immediately after they were written to the screen. Since you were working with only 2 1/2 bytes, and you could only write a full byte, that became somewhat challenging. Especially since the 6507 CPU was clocked at 1/3 the speed of the TIA chip. For every three pixels plotted, you'd get one CPU cycle. To add insult to injury, even the shortest instruction still used 2 CPU cycles. And God help you if you crossed a page boundary while reading or writing memory. The extra cycle you incurred would be enough to throw off the entire program and cause nothing but garbage to get written to the screen!
Making things even more difficult was the way you moved sprites around. There was no way to say "show this sprite at location X". Instead, you had to use one scanline to mark the approximate pixel location of the sprite (remember, 3 cycles per CPU clock), then use the location counter function to advance the position forward or retard it backward by a few pixels. And by a few, I mean 0-3.
As a result, you had to become a master at timing everything. You counted the cycles, you watched the memory locations, and you figured out how to beat the machine at its own game. Which (oddly enough) is more or less how the system was designed to be used. By the end of the 2600's lifetime, developers had pulled incredible graphics out of the system. Some were done with the assistance of special cart hardware, but most of it was simply the ingenuity of the developers.
Re: (Score:2)
right, the game cartridge had 4kb of rom, and later ones had multiple 4kb blocks, up to 8x4kb = 32bk with bank switching.
And don't forget.... (Score:2)
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.
Re: (Score:3, Informative)
Correction, Gov. Schwarzeneggar wanted to partially defer pay to California state workers, and pay them in the next quarter. That's what was impossible. And yes, that seems like it would be a lot of work, even if the language wasn't an issue, with the possibility of breaking quite high.
Re:Another one? (Score:5, Interesting)
I absolutely agree. There is a lot of new COBOL being written, but it is usually done to enhance existing systems.
I am currently on a project at a major insurer on a system that is about 90% COBOL. Over the nextre year most of the Batch functionality will be replaced with smaller Real-time enabled called routines running as headless transactions in a CICS region.
The code base will be greatly reduced because the majority of the field validation is being moved into the new front end web app from the old COBOL based CICS green screens and the Nightly batch routines. The COBOL code will just wait for messages to show up over the Queue and either update, create, read or delete things in DB2.
The software system is really pretty robust for a Mid-80's era design. It has no central database, each separate portion of the company processes transactions in a distributed peer to peer fashion. Quite advanced for mainframe systems of any era let alone when PC's were just breaking into the 16 bit cpu and greater than 640 k era.
Mainframes are much cheaper now as well. The models produced by IBM today run on air cooled power PC CMOS design chips and start in the $300K range (and go way up). Paying for comparable computing power on an Intel based platform would cost less, but if you start demanding the 9 nine's of uptime that mainframes deliver the cost of the high availability Intel based machines goes way up and you get into the $250K range.
People used to believe that 'network' computing would kill the mainframe. Now the mainframe is just a part of the network.
Re: (Score:2)
the majority of the field validation is being moved into the new front end web app
That sounds scary...
Re: (Score:3, Interesting)
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.)
Typical COBOL developer. That's so last century. Don't you know we call them Anti-patterns now? Get with it alread
Re:Another one? (Score:4, Insightful)
Yes and no. In the financial industry, for example, COBOL mainframes hang on primarily because their reliable.
BS. In the financial industry COBOL mainframes hang on because they're PAID FOR.
Re:Another one? (Score:5, Interesting)
Yes and no. In the financial industry, for example, COBOL mainframes hang on primarily because their reliable.
BS. In the financial industry COBOL mainframes hang on because they're PAID FOR.
Almost. The mainframes are definitely not paid for (we continue to lease and upgrade our mainframes), but the COBOL code is.
Mainframes hang on because they have a huge legacy base of working code. Replacing all that is seen as a giant expensive effort for no immediate gain. And because we have more and more work to do with that data, we keep adding more and more code to the legacy base.
It'll take a mandate from on high to get us to stop adding to the morass. And that's not forthcoming, because honestly the COBOL work is still as cheap as anything else, especially for the giant record-oriented processing work that we ask of the beasts. They may not be glamorous, but their ugliness is well understood, and has a stable price tag.
No (Score:3, Insightful)
BSG (Score:4, Funny)
Long Live the Lords of COBOL.
Re: (Score:2)
I'm definitely not counting it out. Galactica and fleet could still settle there now that they've discovered Earth is a devastated wasteland!
Re:BSG (Score:4, Funny)
COBOL? bah! FORTRAN rulz!
-and he said with a face quite solemn: "You better start in the 7th column"
Best Part (Score:5, Insightful)
It may seem surprising that it takes any programming at all to implement a salary change in a payroll system, but a commenter on Slashdot said it was at least plausible, and that's good enough for us.
I think this alone should be enough to discredit the author.
Re: (Score:2)
Re: (Score:2, Insightful)
ROI (Score:5, Insightful)
What many people don't get is that a good business person goes after ROI. If you spend money on something, you want to get money out of it. Squeeze every dime until it screams (which I respect, BTW). Ripping out something just because it isn't cool doesn't play. Enhancing or building on top of it when there is a good business case does play. If it ain't broke, don't fix it.
Having to upgrade every 3-5 years means no ROI. This is a great argument against closed source proprietary vendors.
BTW, there is OO COBOL out there. And FORTRAN 95 is OO as well, which I am ramping up to do a project in soon (I hope).
Re: (Score:2)
> BTW, there is OO COBOL out there.
OO is so twentieth century. Where is the functional COBOL?
Re:ROI (Score:4, Interesting)
Re:ROI (Score:5, Insightful)
Well, that's a matter of being in a hurry go get the program out the door. There's lots of parameter input through the compiler going on. Always has been.
I personally like terse languages, but I think coupling is a bigger issue. Fifty lines of self-contained COBOL are easier to understand than twenty lines of highly coupled Python that depends on assumptions spread far and wide in the system.
One of the reasons that so many COBOL systems remain is that they were written in a day when most tasks ran top to bottom. It was before the "event loop" became a familiar pattern to most programmers. In a sense, it shows how reusability can shoot you in the foot (there's few worthwhile tools that can't be dangerous some of the time). Back in the day the vast majority of programs had well defined input, performed a well characterized calculation on that input, and produced a well defined output. Now consider something that is a component in a framework. It has to be damn well conceived because it's meant to operate in situations the designer has never even conceived of.
So, I'll bet that the COBOL that survives is stuff which does something that is clearly defined, simple, and useful. Why convert it to Java if it works fine and is part of a large body of software that works fine?
Re:ROI (Score:5, Interesting)
Anecdotal.
Properly written COBOL is as flexible as anything else.
Badly written COBOL isn't flexible--just like every other language.
"COBOL isn't very quick to write, what can be done in 50 lines of COBOL can be done in 30 lines of C, and about 20 lines of Python or Java."
and 1 line in perl.
Where do you get your numbers. I can do things in 20 lines of COBOL that would take 100's of lines in C.And it performs faster then those languages. When you are doing millions of financial calculations and hour, you need reliability and rock solid performance.
Re:ROI (Score:4, Funny)
When you are doing millions of financial calculations and [sic] hour, you need reliability and rock solid performance.
When you are posting to Slashdot however...
Re: (Score:2)
I think the issue there is that companies have to rewrite their legacy COBOL in new languages becuase they cannot find anyone who knows COBOL (or charges too much).
COBOL is perfect for its specific domain - batch processing business stuff. I think you'll find that some things (like payroll merges) can be done in 4 lines of COBOL that the equivalent Python or Java would take 1000 lines.
Here's an interesting take [computerworld.com] on the subject.
With the emergence of service-oriented architectures, companies are able to more e
Re: (Score:2)
I don't think it's because they can't find anyone who knows COBOL. Any developer who is capable of learning C++ or Java is more than capable of learning COBOL. In fact, it's the ease with which someone can learn the language that is one of it's strengths. The problem is that developers who work with newer technologies don't want to learn it
Re: (Score:3, Insightful)
Re: (Score:2, Funny)
ADD 1 TO COBOL GIVING COBOL
Still taught in schools (Score:3, Interesting)
Re:Still taught in schools (Score:4, Interesting)
Perhaps you should be grateful that they're teaching you at least one commercially viable language.
When I was in school, we learned several languages that have only microscopic utility in the business world today, and many that exist now only in moldy documentation and hazy memories. Trust me, SNOBOL and PL/1 are not going to get you in any doors. FORTRAN might get you into a few aerospace industries (the kind where the engineers still wear slide rules on their belts.) Pascal morphed into Delphi, and yes, there are jobs for those people (or so I hear.) LISP may still be big (in the (parenthetical (world)) of AI), but good luck finding that job. And I learned half a dozen assemblers for architectures that have now been out of production for over 20 years. Most of today's commercially valuable languages weren't even invented back then: C++, Java, Smalltalk, or any of the .Net flavors. They didn't even teach us C because it hadn't reached our school yet.
But they taught us COBOL. What other languages have you had to take that you know will still be in use 30 years from today? :-)
Re:Still taught in schools (Score:4, Funny)
English comes to mind, but considering some of the posts I see here, I have my doubts.
Wasn't BASIC (Score:2)
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.
Re:Wasn't BASIC (Score:5, Informative)
No, I just switched his COBOL quote out for the BASIC one on my whiteboard at work on Monday.
The BASIC one is
See: Wikiquote [wikiquote.org]
No. (Score:2)
Quote: http://www.informatik.uni-freiburg.de/data/citations/citation.2007-06-26.0532689966/view?set_language=en [uni-freiburg.de]
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."
Baby Boomers + COBOL (Score:2, Interesting)
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."
Re: (Score:2)
COBOL is a 21st century language.
Cost, reliability, and performance are the factors.
COBOL will be here in 50 years.
Re: (Score:2)
I think you dropped a zero. COBOL will be here in 500 years. It's like the dinosaurs in Dilbert: Everyone will think it's extinct, but really, it'll just be hiding behind the furniture.
Re: (Score:2)
Re: (Score:3, Funny)
I think you underestimate how many banks are actually run by immortal (daywalking) vampires.
Two less.
No way (Score:5, Insightful)
and may be the next language you'll be learning
Just impossible. Basically because it was the second language (after FORTRAN) that I learned. I don't really understand the fuss about COBOL. Never found it either much worse or much better than other languages. The thing to remember about COBOL is that it was developed to solve a specific kind of problems. Today we would call it a Domain-Specific Language. And that kind of problems it solves with relative straightforwardness. Most of the critics I see of COBOL are for trying to use it as a general-purpose language. I mean, you don't try to write a text editor in PL-SQL, even if you probably could. And nobody criticizes PL-SQL for that reason.
So COBOL is outdated and verbose. True. So what. It's been years since a wrote a line of the beast, but I wouldn't have a problem to start working with it tomorrow. Also, as the set of problems that it was designed to solve was reduced, it as very pliable to being automatically generated.
So, a language is a language, all have their problems and advantages. Me, I care much more about the size of my screen or the strength of the air conditioning in my workplace than about the particular dialect that I have to program this week.
GOODBYE WORLD (Score:5, Funny)
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.
Re: (Score:3, Funny)
Re: (Score:3, Funny)
Ack! Get that away! It might be contagious!
Old Joke (Score:4, Funny)
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."
Re: (Score:2)
Nice segue into a phrase that sort of tightened my jaw in the DDJ article:
I disagree with that statement. COBOL was the prevalent language of the time so it was mostly manifested on COBOL compiled programs. However, I maintain that any contemporary language that was in as wide a use as COBOL at the time would have been bitten.
Re: (Score:3, Informative)
000010 IDENTIFICATION DIVISION.
000020 PROGRAM-ID. HELLO-WORLD-PROG.
000030 AUTHOR. TIMOTHY R P BROWN.
000040*The standard Hello world program
000050
000060 ENVIRONMENT DIVISION.
000070
000080 DATA DIVISION.
000090 WORKING-STORAGE SECTION.
000100 01 TEXT-OUT PIC X(12) VALUE 'Hello World!'.
000110
000120 PROCEDURE DIVISION.
000130 MAIN-PARAGRAPH.
000140 DISPLAY TEXT-OUT
000150 STOP RUN.
Some c (Score:4, Funny)
#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);
}
}
Re: (Score:3, Funny)
000150 STOP RUN.
Well, which is it, STOP or RUN? I guess we've identified where Apple got the 'drag disc to trashcan to eject' and where Microsoft got 'Click the Start button to shutdown' mindset from.
Re: (Score:2)
Hey, loan me one of your job cards. The keypunch machine ate mine.
cookie.
Why, what trendy buzzwords you have. (Score:4, Funny)
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".
Re:Why, what trendy buzzwords you have. (Score:4, Funny)
Re: (Score:2)
Hahah, thanks. That site is delicious. I especially liked the screen burn effect :)
Next thing you know.. (Score:3, Funny)
they're going to be telling us that Fortran is the new Java.
job market (Score:3)
Re:job market (Score:4, Interesting)
Maybe you shouldn't count COBOL out in terms of it still being used in the business world, but I sure wouldn't base any career decisions around it.
Re: (Score:2)
We are looking, and are people get offers.
I know people making 100 Plus an hour and have been for years.
Maybe those programmers should get out of the boat and work at getting a job~
Of course, the area they are in may not need any right now.
Re:job market (Score:5, Funny)
What do COBOL coders make these days?
COBOL programs.
<rimshot/>
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Not that much [itjobswatch.co.uk], but this is a UK-specific survey. Still, seems there's a steady progress upwards.
Why is Cobol hated? (Score:2)
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"?
Re:Why is Cobol hated? (Score:5, Informative)
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"?
C (No bells or whistles): http://99-bottles-of-beer.net/language-c-116.html [99-bottles-of-beer.net]
COBOL (or as I call it, COBALD): http://99-bottles-of-beer.net/language-cobol-1820.html [99-bottles-of-beer.net]
Re: (Score:2)
Re: (Score:3, Insightful)
You picked the wrong choice to show him why COBOL is hated.
Typical Mainframe COBOL [99-bottles-of-beer.net]
Re: (Score:3, Insightful)
SO?
Comparing the number of lines is a waste of time and shows a lack of knowledge about what is actual important about programming.
Most people don't understand COBOL, and there for think it's bad becasue its old and give crappy examples the show how ignorant they are.
Re:Why is Cobol hated? Recursion (Score:3, Insightful)
Ever tried doing recursion in early Cobol? Maybe they've fixed this in later versions, but in the past the return pointer was stored in program space at the head of the function. This means that if you ever had any recursion, the return would loop back forever. How's that for a 3rd generation imperative language? You have to implement your own call stack!
My main complaint is the verbosity of the language, and the clunky set of program flow verbs. It almost forced you to use GOTO (and indeed, many people
Re: (Score:3, Interesting)
Re: (Score:3, Funny)
Bollocks (Score:2, Insightful)
Seriously I can't think of something that is more rubbish. Yes COBOL is out there, but as a mainstay of XML and Web Services? Are you serious? Have you tried getting an old mainframe to talk in Unicode? COBOL is what old apps are written in and what they are maintained in, its not that there are no jobs but you'd be nuts if you are a talented coder to get into COBOL. If you are 50 and want a pension however its an ideal area to get into.
Yes I know COBOL, yes I have developed and maintained in it, and N
Re: (Score:3, Interesting)
I guess someone who quotes Gandhi showing off his complete ignorance shouldn't be expected to know the many new COBOL apps are used, and there are some very widely used enterprise systems that sue a language very similar to COBOL.
Clarification (Score:5, Funny)
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.
You know the pose (Score:5, Funny)
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?
Re: (Score:2)
If only we had some sort of 'point' to tell people the sentence is exclaiming something..and was used only once at the end of a sentence~
No doubt.... (Score:2)
...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.
Lines of code? (Score:2)
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 [catb.org] moderation ...
Re: (Score:2)
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
I think you're confusing it with Java/C# :)
billions of lines (Score:5, Funny)
"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.
Kobol - the place of the gods (Score:2)
oh lord o cobol, hear my prayer.
now that it has an ELSE statement (Score:2)
"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.)
Gotta have more Perl! (Score:2)
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
Lar
Ya don't say (Score:2)
Pedant alert (Score:2)
Now: allow me to rant on all of you who call it the "Patriot Act". ARGGGGGHHH!!
(There: got my pirate cred in there, too.)
On the topic of old tools (Score:2)
Delightful.
You see where tidier tools have stolen market share from TCL.
poor excuse to get out of Java standards (Score:2)
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.
COBOL is like NASCAR (Score:2)
I think a long time ago, some Oracle Apps were written in COBOL.
As long as there are still mainframes (Score:3, Funny)
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
COBOL on .NET with GTK# (Score:3, Interesting)
This pretty much blows my mind:
http://www.sorn.net/media/photos/blog/cobol-gtk-sharp.png [sorn.net]
The compiler here is called Wildcat, and it's a .NET compiler (runs on the CLR).