Reasons to hate COBOL

If you need to parse or manipulate text (eg. HTML) then COBOL is going to be really irritating. Support for text manipulation is probably the weakest, most miserable, part of the language. Web developers will all hate COBOL for this reason alone (and justifiably so).

If CPU cycles and memory are not limiting factors, then you will find contemporary languages and frameworks can be a lot more productive.

Your job is to maintain a 30 year old application. You are going to hate this almost by definition. Since the only surviving 30 year old applications are probably written in COBOL, you will hate COBOL.

You are attracted to "shiny new things". COBOL isn't shiny or new - and not for you.

Reasons to like COBOL

The core business of the organization you work for is not developing or delivering computer related services/products (ie. you live on the liability side of the corporate balance sheet). Then COBOL is good because it is very stable and probably delivers the lowest cost per transaction in the industry.

The transaction load you have to process is huge. Non-dynamic, non-object oriented languages (read classic COBOL) are better equipped to build high performance, low memory usage transaction processors. This is largely due to a fairly direct correspondence between a COBOL verb and the generated machine instruction set needed to implement it.

You want to build applications that will be operational 30 years from now. COBOL is an evolving language but has a tradition of hanging onto all of its baggage. This is a double edged sword - avoids forced and/or costly upgrades (good), but can contribute to some awful code (not so good - but you can't have it both ways).

Maintenance. Old COBOL code can be (almost always is) ugly but it can be deciphered and maintained. COBOL is a write/read language (as opposed to write once then re-write). Given the heavy emphasis on leveraging frameworks today, I question whether the resulting code will be "readable" once the underlying framework is abandoned for the next shiny new thing. If you question this statement, consider the list of depreciated elements ^[1] for the latest Java release. Compare this to the list of obsolete COBOL language elements ^[2]. The relative sizes of these lists do not speak well for long term Java application maintainability. I use Java as an example only - the same observation applies to all recently developed languages and frameworks (yes, I know Java is "old school" to many of you but it is recent when compared to COBOL).

COBOL is not a Swiss Army Knife

COBOL was originally designed for Business Oriented applications. At that time it meant things like accounting, inventory management and other forms of records management. COBOL is sill largely suited for these applications. If your business is heavily weighted on the processing side of the equation as opposed to the presentation side, then COBOL is a very reasonable language to be using.

A lot of "bad press" COBOL gets is from people who work in application domains for which COBOL is not suited and from those who have never tried to really understand the language (many of whom are academics with a bias for shiny new things).

And by the way, COBOL is still very much alive and in use. We just don't make a lot of "noise" about it.

A big gripe people have with COBOL is the syntax. It was invented by people with the (false) belief that programming languages are easier the more they look like English. Whereas C-based languages have code like:

tax = rate * subtotal;
count--;

COBOL has

MULTIPLY RATE BY SUBTOTAL GIVING TAX.
ADD -1 TO COUNT.

(The COBOL programmers I know really do write "ADD -1" all the time: It's shorter than "SUBTRACT".)

[disclosure - I work for a COBOL vendor]

I think a lot of the issue you describe (there being a lot of anti-COBOL content on the web) is really down to a few things -

1. There's a general negative feeling in the computer-geekosphere about anything "old." For these people the latest scripting language is the place to be and anyone doing anything else is out of touch (you'll probably find a good number of Ruby or Groovy programmers saying Java is too old fashioned, COBOL isn't the only language that gets bad PR). I would suggest that the people that are most active in the blogo- & twitter-sphere fall into this group. Whereas the people making good money out of COBOL or those that are actively moving it forward are much less noisy - they have a good living to make!

2. Posters making the negative comments are not up to date with what modern COBOL is like. You'll hear a lot of comments about a) how verbose the language is, b) how it needs to be formally structured, c) how it encourages bad practise. Every one of these are untrue: a) I don't think there are many languages which can be more consise than COBOL's display "hello world". (yes that is the complete program), b) this hasn't been true for 15 years, c) any language can be written badly.

3. COBOL proponents & vendors haven't done a great job of keeping the world informed of the changes that have been going on and how vibrant and important the COBOL community & application base is. I'd include myself & my company in this group and we're actively trying to do better.

Am getting told about how horrible COBOL is

People love to bash the unknown. Few programmers want to learn Cobol, even though it is one of the most common languages in use, it just ins't sexy. Not like that "C" language that is almost as old as Cobol.

(BTW, the "COBOL" acronym has been a pronounceable word for over half a century (like Scuba, Radar and Laser), can we stop capitalizing it and just say "Cobol"? Please.)

Pretty much any transaction you have that involves money will be processed through Cobol systems at some point. Most of the "data" that government or corporations house about you and your accounts will be processed through Cobol systems.

See sites making fun of COBOL

People love to ridicule what they don't understand. In this thread I have seen some overtly silly claims about Cobol by people who obviously don't know what they are talking about -- but they will say it because it was that way in disk-memory-and-cpu constrained 1974, so it must still be that way, right?

Lets take some common misunderstandings:

• Cobol is "Wordy" or "Verbose": Only if you make it so. Cobol allows a lot of whitespace words that mean nothing, but can be there for 'readability'. In practice, nobody ever uses them, so while some haters will silly examples of verbosity, in practice, you will see all the noise crap removed and simple, understandable, terse statements.

• Cobol is "Old", all the apps were written 30 years ago and the source code is lost, and the programmers are dying: This is just bullshit that Accenture made up to sell y2k contracting hours. For all practical purposes, Cobol is the language of financial transactions. The transaction may be accepted by a javascript web page, a java point of sale, a C++ cash register, but it will be processed, presented and cleared by Cobol systems. They are under active development and there are plenty of programmers around the world writing new apps every day. But they are not sexy -- given the choice between balancing the worlds collective checkbook and writing OpenGL code for the hottest new massively-multiplayer-dougeon, what is the average 20-something geek going to pick?

• In Cobol, everything is Global: Only if you are stuck in a time-warp to 1966. Cobol has always supported the idea of modules -- separate compile units with isolated storage. It also has a facility to declare storage items explicitly globally accessible to all compile units, but only as an option (BTW, C also has this option). In Cobol-85 the concept of "nested programs" was added -- this is identical to a function or procedure in C or pascal -- a stack frame invocation with its own local storage and some set of parameters passed to it.

• In Cobol, you use punch cards and green-bar print: Obviously someone who hasn't used Cobol since the 1970s -- back then, you did the same for Pascal, C, LISP, macroized C-With-Classes (later called C++), et al.

• Cobol loves the GOTO verb: So does C, so does VB, lots of languages allow this abuse to exist. Just because it was used widely in the 70s when that was the only control structure available, does not mean it is being widely used in the tweens(?). Cobol-85 introduced a rich set of control structures that made the GOTO (and its evil twin the Altered GOTO) obsolete.

• One mis-placed period can ruin your life: Not for the last quarter of a century. Periods for control notation have been made obsolete by the ubiquitous END-* construct.

• Every line of functional code starts in column 12 or above. So to add a new line, you must first type at least 12 spaces: True in the punch card days -- not true for a long time. Most compilers have a compatibility mode for older files, but can run free-form text as well.

• Native programmers are mostly brainwashed and incapable of understanding OOP concepts: Object oriented Cobol is alive and well in several flavors. There is native support for objects in the Cobol-2002 standard. Also, for decades before that, most (all) manufacturers of Cobol compilers integrated object support. MicroFocus built their own style of OOP, IBM did too, but also allows for Cobol to interact seamlessly with Java objects, Fujitsu did some other things. Again, this is a case of someone unwilling to learn new stuff after 1974, not a real, valid point.

• [Cobol] is older than Jesus Christ himself: Cobol and C are both well into middle age. They have more in common with each other than they do with young teenage punks like Perl and Java or tweens like .NET, Python and PHP. Why do you hate on one old, fat, balding, middle-aged computer language like Cobol and give C a free pass?

Hear that I should be happy that I don't have to use COBOL, from older programmers

Cobol is actually a very nice language for some things. It is perhaps the richest AND easiest data definition approach of any language -- you get to lay out every byte exactly as you want it, with exactly the type you want that byte to have. There is a down side to this -- you get to lay out every byte exactly as you want it, with exactly the type you want that byte to have. Super-flexible or super-easy. Pick one.

FWIW, I know and use a dozen languages on a routine basis and I rather like Cobol for many things. Some things are not a good fit, but anything you can do in C (except bit-twiddling) you can do in Cobol easier and with less pain.

See others make anti-COBOL-ist jokes

Well, learning Cobol does seem to be a great form of birth control...

In conclusion:

Seriously, you should learn Cobol. It is an excellent language to know even if you don't use it ofter (or at all). As Alan Kay (father of SmallTalk) once said "A language that doesn't change the way you think is not worth knowing" (or something like that). Cobol's best feature IMNSHO is the data description flexibility. But it is an all around good general purpose language and worth adding to your toolbox. If you decide you hate it after you learn it, you will know your reasons. But I suspect you will find it to be an easy and flexible tool that you will use from time to time.

I still remember some of the things we'd put in our programs 35 years ago when I studied COBOL

Professor Stern would see things like this:

 DIVIDE STERN INTO MANY-PIECES GIVING JOY-TO-STUDENTS.

I also liked

 PERFORM IMMORAL-ACT UNTIL POLICE-ARRIVE

Before I give my (late) answer in response to some of the other answers, I'll give you a little summary of my background.

I learned various languages (mostly C, but no Cobol) at Edinburgh University in the mid-80s, including a look at OO programming with SmallTalk. Came to NZ in 1990 and got a job at my present company programming C and Cobol (which I had to learn). As a young punk fresh out of university, I thought Cobol was a bit 'beneath me' at the time, but soon settled into full-time Cobol programming. In 1999 I was given the job of rewriting the present system in the OO 4GL 'Forte TOOL'. That lasted a couple of years before Sun bought out Forte and killed it. After a few more years of Cobol we started the present project of rewriting the system in Java, using Spring, Hibernate, EJB3, etc.

If I had a choice out of all the programming languages I've used, I would use Cobol. In the 20-odd years I've been programming in Cobol there has never been a time that I've had to say. "No, I can't do that in Cobol". In fact, here in this office we have a tongue-in-cheek saying: "You can do anything in Cobol".

Our present system contains almost 4 millions lines of modularised Cobol code and is used by our Customers (meat processing plants or abattoirs) to track every aspect of their production from the buying of animals on farms, through slaughter and tracking of individual Carcases, to the packing/labelling/shipping of boxes of meat cuts.

Over the years, in Cobol, we've written software which:

• is client-server
• is multi-threaded
• is GUI
• talks HTTP to web-services
• uses sockets to communicate with dozens of different devices such as label-printers, weigh scales, PLCs, meat probes, barcode scanners, etc.
• is 'real-time' (some production processes require split-second timings)
• interfaces with many third-party systems
• has 'Cobol-CGI' web modules used to display Cobol data in a browser

The latest Java project that I've been working on in the past 6 years has shown me that modern languages are not the silver bullet they are made out to be. So far we have only rewritten about a 5% equivalent portion of the old Cobol system and it's taken us 6 years (about 40% of the time it took us to write our whole Cobol system!). So far we've written over 3 million lines of Java code.

Moving from Cobol to Java literally felt like getting back down on my hands and knees and crawling. That's despite the extensive use of complex tools and frameworks like NetBeans, Maven, Spring, Hibernate, Felix, etc. to do a lot of the 'work' for us.

In Cobol, if one of our almost 3,500 modules has a bug in it, we can patch that module, ship it to a customer site (only a few kb), copy it over the top of the existing one and the bug is fixed instantly. Most times the user doesn't even need to log out. Try doing the same thing with a patched Java Class definition in an EAR or WAR! Some of our Customers operate 24/7 with 99.99% up-time. We simply cannot tell them they need to log everyone off, shut down the server, install the new EAR/WAR and then restart the server. Have you ever had several hundred big, hairy meat-workers, who get paid according to production throughput, standing around with sharp knives waiting for your software to restart?

So why are we rewriting? Mainly because young upstart IT managers from prospective Customers take one look at our 'green-screens' and mentally switch off. Because of the perception of Cobol as an old, crap programming language, we have to bring ourselves 'up-to-date'.

We're also aware that the remaining Cobol vendors are now in a cannibalistic phase of consolidation as their market shrinks, and it won't be long until they're all dead, along with the last of the Cobol-trained programmers.

I hate COBOL because...

• There is no variable scoping, everything is global
• It has a GO TO statement that everybody seems to love
• Formatting data (dates, dollar amounts) to be displayed is never fun
• One mis-placed period can ruin your life
• Nobody writes a new program from scratch, they copy a production one and change accordingly
• Every line of functional code starts in column 12 or above. So to add a new line, you must first type at least 12 spaces.
• Native programmers are mostly brainwashed and incapable of understanding OOP concepts
• It is older than Jesus Christ himself

Regardless of all these negative things, COBOL is probably the most mature programming language of all time, and it has proven itself in the business world to be extremely reliable. Sometimes I find myself changing a COBOL program that was written 30 years ago, and I wonder if somebody else will be doing the same to my ASP.NET web applications 30 years from now. Somehow I doubt it!

Well COBOL isnt such a bad language for something put together by a committee in 1959.

However there are some deeply serious shortcommings:

1. No function calls. There were recently a number of functions added to the language. But there is no way to easily define your own function calls, and, if a function is not supplied with the compiler then its just not there.

2. No type checking on subroutine calls. While COBOL is strongly typed within a single module there this is no type checking on parameters passed from one module to another. This causes so many problems that I have seen coding standards that more or less ban modular programming.

3. No standard libraries. If its not a build in language verb then you write it yourself.

4. While the language has crawled slowly into the twenty first century, most of its practitioners have not. So criticisms about 1970s COBOL still apply to current programs even though there are now better cleaner ways to write COBOL.

There are however many "negatives" made in this thread that are misleading or untrue.

• It's verbose : While MOVE X TO Y may take a few more characters than Y = X the structure and file definitions are quite succinct, and things like automatic type conversion etc. make it much less verbose and easier to read than Java or even C++.

• No multi-threading : true there is no built in language support for threads, but, this is mostly because it was never required. Multi-threading and multi-tasking has always been handled by application containers like CICS and IMS/TM, there was never any need for it within the language itself.

• String Manipulation -- Cobol's STRING, UNSTRING and INSPECT verbs are pretty useful and at least as good as Visual Basic hodge podge collections of string functions. The TRANSFORM verb was really nifty but is now depreciated or unavailable.

• Bit manipulation -- is actually supported in several/most dialects of COBOL either natively as a "PIC" type or with built-in functions.

Additionally there are several areas where COBOL shines and is markedly better than many, most or all other languages.

• Decimal arithmetic. Decimal arithmetic is built into the language. Fortran, C, C++ and Java cannot native types cannot due decimal calculations correctly according to accounting and tax regulations. (VB can!).

• Database Integration. It may implemented as a "pre-compiler" but its easier to code up SQL and manipulate results in COBOL/DB2 than in anything else (Pro C excepted). Its just so much simpler and easier than any ORM or ADO to code.

• File handling. You see a lot of posts complaining about "COBOL" files. There is no such thing, they just happen to be files that can be read and manipulated by a COBOL program. I have never yet come across a file format that could not be handled by the standard COBOL file definitions and verbs.

• XML integration. Built into the latest compilers and implemented simply and elegantly.

• Screen Handling (Nearly forgot this one!). Cobol's screen handling is just superb. Simple elegant and clear. Compare and contrast with the "ncurses" library.

I'll quote Robert Glass from Facts and Fallacies of Software Engineering ^[1]..

COBOL is a very bad language, but all the others (for business data processing) are so much worse.

He goes on to explain its benefits (has most of the language features that a business programmer might need like fixed format data structures, penny accurate calculations, etc.) and its faults (mostly syntatic) and ends with an interesting statistic...

Each year, practitioner surveys show that COBOL usage will be considerably lowered the following year. And each year, COBOL is found to be the language with the largest increase in usage.

Take that with a grain of salt, the book was published in 2002.

I think most of the hate stems from the syntax, and because distaste for it has become an easy way to spark conversation among fellow programmers.

Some of the stigma comes from Old School COBOL, which was truly painful. I had to write COBOL on punchcards for a course years ago. We had terminals and more modern languages like PASCAL, but this legacy horror still existed:

1. Write program out on big sheets of green paper, with character-sized grids, one character to a cell. This was particularly painful, as COBOL was terribly verbose.
2. Drop off paper at data center.
3. Come back later and pick up stack of cards (your program typed up by the kindly keypunch operators).
4. Check cards for typos.
5. Use a keypunch machine to redo any cards with errors.
6. Drop batch of cards off at data center.
7. Come back later and pick up stack of printout, usually errors.
8. Debug errors by inspection.
9. Use a keypunch machine to fix cards with bugs.
10. Go to step 6.

This certainly wasn't all COBOL's fault. More modern COBOL compilers have improved some of the faults of the language, or so I've heard. But after that experience, I have no desire to go anywhere near it.

I hated it because COBOL programmers tended to write emails IN CAPS BECAUSE THEY FORGOT TO TURN OFF THE CAPS LOCK KEY, AND COULDN'T BE BOTHERED AFTER THEY'D TYPED IN HALF THEIR EMAIL ALREADY ANYWAY.

At least I don't have to worry about being shouted at in email any more now that I've moved on :-)

COBOL, Lisp, and FORTRAN are the oldest higher level languages. COBOL is generally associated with legacy mainframe applications.

It's possible to write clean (and spaghetti) code in any language.

I believe COBOL has subroutines, so it's possible to write it in a well-decomposed, top down, modular style. COBOL that is written using a copy and paste style can be voluminous and hard to understand.

But COBOL's not a joke. It powers a lot of software that runs large companies.

People that write COBOL live in a mainframe world and don't deal with distributed, object-oriented ideas that you take for granted in more modern languages. Maybe that's why people say you should feel lucky to not write it.

I've never written COBOL; can't read it, either. No desire to learn.

COBOL predates a lot of things that modern programmers - who have only learned more recent langauges - take for granted.

Largely, the programs were written by people who don't think like you do. They were never exposed to OOP, for example, and design patterns weren't formalized until the late 80's/early 90's. I compare it to watching a C++ girl talk to a VB guy. They don't have much shared basis for technical discussion, although they both produce fine code at the end of the day.

As one commenter reminds me, COBOL was largely insulated from the good ideas in programming as early as 1970.

Djikstra had a real zinger of a quote ^[1] that's worth reading again. I'm fairly sure, stretching my previous analogy, that he'd feel the same about VB.

As a general summary, if you want a steady job in the financial industry, absolutely learn Cobol. Your job will be in a large, incredibly structured organization, probably one that favors following tried-and-true process instead of empowering developers, for what it's worth. The benefits will be good, the pay will be average, and the hours will be 40. You will be employed until you're ready to retire, as long as you're any good. You will not learn anything new while you're at it, unfortunately; once you have the swing of things, that's what you've got to work with for 20-40 years.

If you do not want an incredibly stable job working for a bank, and especially if that job description makes you scquickly, Cobol sucks.

I can give you a personal outlook only given what I did with COBOL and what I did after COBOL. I hate COBOL because it is incredibly verbose while being at the same time incredibly inexpressive. Any one of those two things is tolerable (albeit not desirable) in a programming language. Having both together in the same language is deadly. Working with COBOL after seeing better languages always made me feel very much like I should be using an axe to program the system.

Mark's answer ^[1] on this has a lot of truth to it. "Modern" COBOL (scare quotes because even the most modern of COBOLs is not a modern language in my view) is vastly superior to the stuff I had to code with. This is largely irrelevant, however, because practically nobody actually codes with modern COBOL. They use modern COBOL compilers to write ancient-style COBOL code much like a lot of "C++ programmers" basically just use it as a slightly better C, so basically you're still using incredibly verbose (and sometimes obtuse) syntax to do simple, mindless tasks because you can't do interesting or challenging tasks with the language unless you're a dedicated madman.

That being said, the few remaining COBOL dinosaurs out there do command huge salaries because of the combination of their rarity and the business value of the software they maintain. (Very few people make software in COBOL anymore!) I just think, in the end, that there are things more important to me than making money.

COBOL is not bad per se, but it is indeed a 1959-born technology dinosaur mainly used for writing dull and uninteresting accounting software.

"The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense." E.Djikstra

What about COBOL lacking the followings:

Resouce allocation/sharing concurently with other processes

No multithreads support

No reference to bits

No logical operations between variables

weak library support

"Djikstra had a real zinger of a quote that's worth reading again."

If it were up to Dijkstra and his crew, the only programming language in the world would still be ALGOL/60 (yes, the number refers to a decade).

And if it were up to Dijkstra all by himself, even that language would be disposed of in favour of (heaven forbid) LISP.

Referring to one of his famous oneliners, half of his writings expose a level of arrogance (and, alas, crappiness as well) that can only originate from the Dutch.

The art with any of his writings is to determine whether it belongs in the "indispensible readings" half rather than in the "angry-and-frustrated scientist's overzealous crap" half.