COBOL excels at moving data from file to file. I haven't seen the Redefines capability in any other language and is very very powerful when it comes to slicing up data before transformation and then putting it back together in other formats.

Of course, nothing can touch the combination of mainframes and COBOL when it comes to processing millions and millions of records.

But, it IS a dinasaur. It was one of the very first computer languages there were. It was a milestone in computing history. From the Yale page about Grace Hopper [yale.edu]:

Pursuing her belief that computer programs could be written in English, Admiral hopper moved forward with the development for Univac of the B-O compiler, later known as FLOW-MATIC. It was designed to translate a language that could be used for typical business tasks like automatic billing and payroll calcula

Really COBOL, in the last iteration I worked with it in at least, had 'caught up' with the times in alot of ways. 10 years ago I learned OO COBOL, which really made COBOL alot like C++. Though COBOL was sort of limited in IO: files, text to screen, and at most pixel switching for primitive graphics. No fancy GUI's here. Most of COBOL though was about file interaction, bring stuff in, work on it, and output once more. Sometimes with user input, though often not.

The combination of Mainframes and COBOL is the Catapiller D9 of computer system. When it comes to moving mountians of data through the system, the girlie languages running on PC farmes just can't keep up.

I'm not a programmer by trade, I'm a network 'engineer'/'administrator'. What I learned in programming stopped at Java/C++ (C++ being taught within a Java environment actually). So the latest wizz bang language are thinks outside my scope.

However 10 years ago OO was a key factor in 'modernizing' COBOL. Saying that those things didn't make COBOL 'catch up with the times' by matching what was then easily the most popular coding language (remember Java was very new then) of the time... Well that sure seems 'ca

It may be crass to admit, but I had some great experiences working in my first COBOL position. Sure it dates me...so what, I got a lawn and am proud of it. I do appreciate the development tools I use as a current developer, but something about the simplicity, and the structure make me feel nostalgic. Lately I see code with no documentation, no good structure and buggy. COBOL, FORTRAN, and Pascal separated IT programmers (and staff) from middle managers and office workers that today think writing an Access VBA makes them a.net developer. You can't go back (nor would I, but for the need of a job), yet I would like to see some of the foundations that went into development groups make a comeback.

I guess I just need to go out and learn Fortran for the old school trifecta!

I know my first year CS they taught Pascal, and then changed standards to C the following year. Thanks for that. COBOL was, and probably still is taught for those students with high pain thresholds.

I don't actually program for a living (though I use scraps here and there), so I don't have all the new sexier languages. I know the few times I have applied for a new positions, having those languages and stuff like Assembly, etc... on m

So true. I'm glad my boss doesn't have that philosophy. Recently there was a bunch of work that needed to be done in ActionScript 3 for a project in another department and my boss came to me knowing that even though I'd never used the language, I'm a good programmer and I'd figure it out. Mind you, you'd have to at least be familiar with OOP, but that's not exactly new or trendy any more...

I would add ALGOL PL/1 and MIX to that list of oldies.
PL/1 was my first. I paid 10 dollars for a programming language manual in about 1976 and didn't eat that week, but I had the most curious week of reading... Proc Options (Main); humm
the rest is blue screens and history....

I remember seeing ads for COBOL programmers in the careers section of the paper throughout the 1990's... with steadily increasing salary ranges, right up until about mid-October of 1999, where I was routinely seeing offers 80K per year or sometimes even more for new grads, it seemed that there were quite a few companies getting desperate to have COBOL programmers.

Then, suddenly, within the space of only a week or two, the COBOL programmer ads stopped.

Because, once the Y2K bug was fixed, those systems that were already probably working just fine with 20-30 years of minimal maintenance and one huge spurge of Y2K updates will carry on running, most probably. Or people took it as a sign that maybe it's *not* a good idea to be relying on code that nobody on your staff can understand in order to run your business.

nonsense, COBOL is still used in code that moves money and processes insurance claims. I've been a part of adding new features with newer technology to some of those systems even in the last year. Still going strong, still people maintaining code bases of COBOL and related languages such as RPG and very old JCL. And no, we don't put the COBOL and related parts on our resumes either 8D

I had to learn JCL for work (took a college class, paid for by my employer). JCL is a scripting language, like Perl, not a database language. It stands for Job Control Language. IINM I still have a thick, hardcover book on it. If you look it up on wikipedia, the article's editor compares it to DOS.

COBOL would be more like NOMAD (I loved NOMAD).

I'm unfamiliar to RPG.

How many closet dinosaur-language slashdotters are there?

IIRC it was the late '90s I learned JCL. I did hand-assemble machine code for the Z-80

Here's another, although my COBOL programs run on an AS/400 (a.k.a iSeries, system I, whatever the heck IBM has decided to call it today) instead of Really Big Iron. Some of the code that I wrote on a CISC-based System 38 over 2 decades ago is still running on a Power6 RISC-based system today, with nary a recompile involved.

Now COBOL is basically used in years-old legacy code which is held together by the programming equivalent of duct tape. And nobody wants to touch that mess. Oh no.

While that's likely true, it's hardly unique to COBOL.

Any codebase which is over, say, 5 years or more, is likely creaking under its own weight and nobody really knows how all of the parts work anymore.

The software also likely runs day in, day out, 365 days/year, and does everything it has been developed to do. I've seen projects that try to replace such legacy systems -- after you've spent millions trying to write something new which does most of what you need, you discover that there's huge gaping holes in your coverage, and you're nowhere near where you'd need to be to replace it. Often, the project gets scrapped at that point as people realize you're never going to be a viable replacement.

Hell, I knew a guy in the 90s who was retired from a company, and drawing his full pension, and working as a consultant at big $$$ rates to maintain the stuff he did before he got paid. All said and done, he was making about 4x in retirement what he made before he retired. They simply had no other people who could have possibly had the 30 years of experience he had on this mammoth system which ran on mainframes.

Trying to get rid of that old creaky legacy code is nigh on impossible in some cases.

and the low bid was probably made by some young programmer who doesn't apriciate the scope of the project

Not hardly. This was several senior people on both sides all trying to capture requirements and understand the scope. By necessity, their own senior people had to limit the scope of the initial project.

Over time, however, you discover everything that the legacy software does... and frequently discover that half of what they told you about the system is utterly false, and the other half was woefully incomplete. So, everything you've built in that depends on your understanding of uniqueness, scope, and content... well, suddenly none of that is true (and quite possibly never was across the whole system).

The trick is getting managment on the ball enopugh to identify people able to complete the project and willing to pay them, in spite of the fact that some other firm gave a lower quote.

I question if you've been involved in replacing a legacy application with 30+ years of history and data in it.

This isn't about people not being on board, or some lame-ass low bid by someone who didn't understand what they'd gotten into. Some of these systems have effectively been built up iteratively over decades, and are business critical. Replacing them can be completely non-trivial... and, in some cases, almost insurmountable without massive investments.

There was once a COBOL programmer in the mid to late 1990s. For the sake of this story, we'll call him Jack. After years of being taken for granted and treated as a technological dinosaur by all the UNIX programmers and Client/Server programmers and website developers, Jack was finally getting some respect. He'd become a private consultant specializing in Year 2000 conversions. He was working short-term assignments for prestige companies, traveling all over the world on different assignments. He was working 70 and 80 and even 90 hour weeks, but it was worth it.

Several years of this relentless, mind-numbing work had taken its toll on Jack. He had problems sleeping and began having anxiety dreams about the Year 2000. It had reached a point where even the thought of the year 2000 made him nearly violent. He must have suffered some sort of breakdown, because all he could think about was how he could avoid the year 2000 and all that came with it.

Jack decided to contact a company that specialized in cryogenics. He made a deal to have himself frozen until March 15th, 2000. This was a very expensive process and totally automated. He was thrilled. The next thing he would know is he'd wake up in the year 2000; after the New Year celebrations and computer debacles; after the leap day. Nothing else to worry about except getting on with his life.

He was put into his cryogenic receptacle, the technicians set the revive date, he was given injections to slow his heartbeat to a bare minimum, and that was that. The next thing that Jack saw was an enormous and very modern room filled with excited people. They were all shouting "I can't believe it " and "It's a miracle" and "He's alive ". There were cameras (unlike any he'd ever seen) and equipment that looked like it came out of a science fiction movie.

Someone who was obviously a spokesperson for the group stepped forward. Jack couldn't contain his enthusiasm. "It is over?" he asked. "Is 2000 already here? Are all the millennial parties and promotions and crises all over and done with?"

The spokesman explained that there had been a problem with the programming of the timer on Jack's cryogenic receptacle, it hadn't been year 2000 compliant. It was actually eight thousand years later, not the year 2000. But the spokesman told Jack that he shouldn't get excited; someone important wanted to speak to him.

Suddenly a wall-sized projection screen displayed the image of a man that looked very much like Bill Gates. This man was Prime Minister of Earth. He told Jack not to be upset. That this was a wonderful time to be alive. That there was world peace and no more starvation. That the space program had been reinstated and there were colonies on the moon and on Mars. That technology had advanced to such a degree that everyone had virtual reality interfaces which allowed them to contact anyone else on the planet, or to watch any entertainment, or to hear any music recorded anywhere.

You're not looking in the right places, here's 4,500 COBOL jobs http://www.indeed.com/q-Cobol-jobs.html [indeed.com] . Major city newspapers list them also.
Latest COBOL is COBOL 2002, which includes object orientation (already de facto standard since early 90s by the major compiler vendors), web and XML extensions, locale sensitive processing, cobol javabeans. The next version is shaping up already, dynamic tables, structured constants, ISO 8601:2000 dates. Propose new extensions for the next version of COBOL

within my company there are some internal vacancies for COBOL programmers, they need about 10 of them. Compared to my current job the work actually seemed interesting, so i asked an older colleague if i should look into it further, his suggestion? "start updating your resume"

The company i am starting with next year also has a COBOL group, they gave it the most brilliant euphemism for a name "proven technologies"

So there still is work, but upon closer examination, i would have to be mental to go down that ro

Their area of expertise is corporate accounting, business methods and procedures.

Practices which have evolved over hundreds of years and practices which the newly minted mainframe programmer is not going to master overnight.

COBOL syntax has often been criticized for its verbosity. However, proponents are quick to note that this was an intentional part of the language design and considered by many to be one of the COBOL's strengths. One of the design goals of COBOL was for COBOL code to be readable and understandable to non-programmers such as managers, supervisors and users. This is why COBOL has a very English-like syntax and structural elements--including: nouns, verbs, clauses, sentences, sections, and divisions.Consequently, COBOL is considered by at least one source to be "the most readable, understandable and self-documenting programming language in use today...." Not only does this readability generally assist the maintenance process but the older a program gets the more valuable this readability becomes."Additionally, traditional COBOL is a simple language with a limited scope of function (with no pointers, no user-defined types, and no user-defined functions), encouraging a straightforward coding style. This has made it well-suited to its primary domain of business computing--where the program complexity lies in the business rules that need to be encoded rather than sophisticated algorithms or data structures. And because the standard does not belong to any particular vendor, programs written in COBOL are highly portable. The language can be used on a wide variety of hardware platforms and operating systems. And the rigid hierarchical structure restricts the definition of external references to the Environment Division, which simplifies platform changes.COBOL [wikipedia.org]

They also announced a COBOL App Store so users could easily find and install useful applications. The inaugural app was "Angry Birds" for the Honeywell 200. Ordering this app will have a box with the punch cards delivered to your house, and a complete installation manual. The second offering was a fart app for the UNIVAC series.

In The Tao of Programming: The Tao gave birth to machine language. Machine language gave birth to the assembler.
The assembler gave birth to the compiler. Now there are ten thousand languages.
Each language has its purpose, however humble. Each language expresses the Yin and Yang of software. Each language has its place within the Tao.
But do not program in COBOL if you can avoid it.

Yeah, it is real easy to get all snarky about COBOL. I have always hated it even though it was a popular language when I was in school (late 70's). My CS department had three separate non-overlapping courses you could take.

The thing is that just about any programmer, even if they don't know COBOL, could go in and change it. COBOL is readable. The record based functionality is simple to comprehend. Something written 30 years ago is still running because there is nothing wrong with it. It does what its supposed to do. It was the perfect solution to the most important business problems of its day, and that legacy is why it is still around while other languages of its era are not.

Should new programs be written in it? HELL NO!!!! The problem set to which COBOL applies is pretty well solved. The new problems require new solutions.

Well, gee... I must be imagining the over 100 new COBOL programs I've written over the past seven years. You see, I do this for a living, and make a pretty decent living at that. I work for an insurance company. The policy and billing management systems are implemented in COBOL on an IBM mainframe, and if we want to keep pace with our competitors, new development is essential. Recently we upgraded the web interface external clients use to access our billing data. While that involved a lot of web desig

Obviously nobody at the Smithsonian ever had to write a program in COBOL!

I have a story. I once worked in a factory where the computer systems were written in COBOL, and it, to put it politely, sucked. We needed data to manage our jobs in the shop and buying requests to fill our orders but there was no way to get the data the way we needed it. After surviving a layoff I inherited a PC with a 3270 terminal emulator card and proceeded to reprogram the board to extract information off of the on-line CICS sy

Turbo Pascal and Microsoft BASIC were the only choices back then, other than assembler. At least with Pascal you could add in some mixed assembler to work with interrupts and low level BIOS logic. Try that with MS BASIC from that era. C compilers for the PC came out over the following year but they were a little unstable. I bought 'both' books on the C Language in preparation for some real programming, and later when it came out I bought my first C compiler (Borland Turbo C) for the PC and rewrote the libra

Because if a woman could do anyone can!Wow that doesn't come out right.Grace Hopper got an early admission to Vassar at the age of 17! She would have gotten in at the age of 16 but her Latin scores where too low..She got degrees in physics and mathematics at Vassar, Masters in both at Yale, then a PH.d. in Mathematics from Yale.She was not just anybody. Frankly she would make most us look like low grade morons. If she was 30 today Google, Microsoft, Intel, IBM, and Facebook would all be after her. She was

Cobol might be a pretty easy joke for obsolescence, but remember that Cobol was written by a woman [wikipedia.org] in a time where the industry was far more male dominated than it is today.

This was surely an impressive achievement. And for 1959, COBOL was surely an impressive language. It's no disrespect to Hopper to dis COBOL based on the standards of the '70s, or '80s, or '00s, however. That's a dis to the folks who should know better, and yet continue implementing the damn thing.

Despite all (justified!) COBOL bashing, you'll have to concede that a 50 years old COBOL compiler could (had to) run on a VERY modest amount of RAM... something that isn't immediately obvious, considering that compilers of current languages are true resource hogs in comparison.

considering that compilers of current languages are true resource hogs in comparison.

In many cases this is due to significantly better optimizations produced by the compilers, however. E.g. in case of C++, modern compilers do full program optimizations - that's millions of lines of code for large products - analyzing code that is sometimes removed from each other by multiple levels of function calls to aggressively inline, do smart register allocation tricks etc, which give very noticeable performance improvements. Compilers of COBOL age (not just for COBOL, but for other stuff) were much m

Disaster? Hardly. Let's see where "insert your favorite language here" is after 50 years.

A recent Gartner study found COBOL in about 75% of enterprise business processes still today. There are an estimated 200 billion lines of COBOL still in use today (at least as late as 2004), with around 2 billion new lines being added each year.

There is considerable controversy about the accuracy of the 200 billion lines, but nonetheless, I would hardly classify this kind of success as a disaster.

Its a good perspective; but cobol seemed 50 years old 25 years ago when I learnt it. It is weirder that UNIX is 40, and C somewhere around 35.C still seems very spirited, despite a few rounds of standardization, and its weird dialects.UNIX has suffered more with prosthetics, but I'm amazed at the range and breadth of applications of modern UNIX; much of the credit for that goes to linux.

But COBOL was one of if not the first "high level" languages. c was came after COBOL, after FORTRAN, after bpcl, after Algol, after Lisp, after PL/1, after APL, and after Pascal.Of course c aged better because it had decades of evolution of programing languages behind it. COBOL has fallen out of favor and I will admit that it isn't a fun languages. But most of the people posting about how terrible it is have never used it. It is still used today so it must have worked very well indeed.How many systems tod

C still seems very spirited, despite a few rounds of standardization, and its weird dialects.

C is low-level enough that the number of concepts it has to deal with is surprisingly low. Getting those right (or, really, "good enough", because C is by no means a perfectly designed language) is not all that hard. And once you have it, there's little reason to replace it with something else in this niche - there are simply no benefits to do so.

Even if today it was down to 1 line of code, just because it has faded doesn't make it a disaster. It ruled the computing world for decades. Now, i agree, its 'just' a *huge* player in the back office, and if it vanished tomorrow we would be in a world of hurt.

Some of the deficiencies you point out are no longer the case. COBOL has evolved a lot in the last 25 years including getting rid of the punch card format.

Don't get me wrong, I'd rather not program in it but it's no where near the horror it used to be. I agree it's unlikely anyone would create a new application in COBOL but there is a lot of business rules and knowledge coded in the millions of COBOL applications out there and there's no reason and no cost justification for throwing it all away.

I used to program in Cobol and I used to measure my code in the number of feet of paper that the lineprinter would print instead of lines of code. Even the "Hello World" program would be more than 1 foot in length...

In the 1401 days, there was a Fortran compiler that used 63 passes of compiler against the source text. When it was done the text was replaced with executable code.

They decided to write a Cobol compiler. What else, they wrote it in Fortran.

Hello world compiled in 30 minutes.

When the 360's came out, they could compile Fortran before the last punch card fell in the hopper.