Code inertia. Huge amounts of existing code written in COBOL = prohibitive costs to switch everything over to another language. Wikipedia says there are over 200 billion lines of COBOL code in use.

Policy inertia. The places where COBOL is really in deep use tend to be government agencies and large businesses, which are notoriously slow to change.

Human inertia. People who make their living writing code and know many languages are less likely to consider it a big deal to learn a new one. People who learned one language because they needed to know it to perform what s otherwise a "business" job may not even think to switch.

I m not so sure COBOL is preferred by big business and government. I would say tolerated might be a better word.

Why?

1. Because big government/business is risk adverse when it comes to managing their financial systems. Screw up here and the whole enterprise is put into jeopardy. If it ain t broke don t fix it.

2. It is difficult to make a solid business case to replace mission critical systems containing millions of lines of code over what boils down to a "my language is better than yours" type of argument – ok its more complex than that but coming up with a solid business case is difficult.

3. Transaction volume. COBOL applications tend to be optimized for throughput. Batch processing large amounts of data is where COBOL really shines. Java applications are somewhat harder to optimize for throughput because of the tendency to have more infrastructure layers between the program and the "metal" which adds processing drag. Big business/government have a lot of data to push through their systems and throughput is essential.

4. Cost per transaction. COBOL generally has a lower cost per transaction when all factors are included. This is partly because processing time costs money, and COBOL applications are generally more efficient. However, COBOL applications seem to have lower development/maintenance costs too.

Before everyone jumps all over me for that last point let me explain...

I work in a very large shop and a few years ago an executive decision was made to build all new systems in Java. COBOL was going to be retained only for maintenance of the existing legacy software base. A complete phased out was planned for a 15 year time horizon.

Some of the best and brightest Java minds were brought in to train, set up Best Practices, build infrastructure and support for large scale Java development. This initiative was well planned and executed. Then, after a number of Java applications had been deployed the "bean counting" started. The results were that COBOL applications still cost less to develop, maintain, support and run - long hard number crunching here because the result was not welcome!

COBOL is back - but not completely. The new executive direction is to keep COBOL for heavy lifting (back end transaction processing) and batch oriented applications. Basically COBOL is to be used for number crunching and business rule implementation. Java comes to the front to provide GUI type interfaces and light-weight processing.

I suspect this is probably the industry trend. COBOL isn t going to disappear any time soon, but it may slip out of sight behind the scenes where it supports new players up front.

First - I work for Micro Focus - so I am an interested party. However, I would turn the question back on its self. Why not? The inherent assumption is that C++, C# or Java are naturally going to be better because they are newer. However, COBOL has not stood still. Partly because of its wordy syntax, it has proven possible to add new features to COBOL so it has remained competitive. People quite often talk about how bad COBOL is, but are comparing 30 year old COBOL to the latest version of C#, Ruby, etc.!

Indeed, the very history of COBOL is evolving, but it remaining backward compatible is a strong reason for a business to invest in it; the TCO is reduced because there isn t any need to rewrite.

For more on the very latest version of COBOL - check out the community site for Managed COBOL:

http://knol.google.com/k/alex-turner/micro-focus-managed-cobol/2246polgkyjfl/4

Why did it catch on ?

Because in the late 1950 s the US government decreed that if a software vendor wanted to sell an app or write an app for the government, the language had to be cobol.

As a consequence, for decades long it was the language that had the largest set of compiler vendors supporting it, and it was the language with the highest degree of ISO standardization, with only FORTRAN getting anywhere near that, but FORTRAN obviously had a completely different target audience.

Second reason : because even today, it is better than any other language I know for certain aspects of certain business problems that occur fairly frequently. The most important of these aspects is decimal arithmetic. Cobol has it natively (as is the case for PL/1 and such), but that is not true of any of those allegedly "more modern" langauges. Incidentally : that is the very reason why there are so many questions here regarding "what is the best data type for storing money values ?". The people asking those questions know no better than that the entire IT world consists of some OO language and some ORM tool, and have no idea of why such a thing a "money arithmetic" might be useful for a computer language to support it natively, i.e. for a computer language to have a built-in, native data type for it, other than bigint (with the programmer still having to keep track of the number of decimals), or float (with the programmer still being responsible for adding the correct rounding logic all over the place).

None of these languages offer what Cobol does -- fast, efficient processing large batches of data. It doesn t need graphics, it doesn t need bit-twiddling, it just needs to do what it does well -- accounting mostly.

C++ and C are ok substitutes for systems style stuff but they fall down on fixed point math and strong support for record oriented I/O. In the space where most financial and business apps live, z/OS, both Cobol and z/assembler have better native support for those things.

Java is good, safe, and workable. And on IBM mainframes, Java and Cobol interoperate very nicely. But some things that are easy to do in Cobol are very hard to do in Java, and the converse is true. They are complementing each other, not replacing each other. Java also does all it s fixed point math via library calls, which are much slower than native opcode support.

Python uses library (aka module) support for fixed point math as well as record I/O. It also suffers from a fatal, IMHO, design flaw of using indentation to delimit scope. This works reasonably ok in the relatively homogenous environment of Mac/Windows/Unix with some variant of ISO8859-1 character sets. It is prone to problems when moving back and forth between an ASCII-centric world and an EBCDIC-centric world where line terminators are not as simple as " , , " and any misconfiguration in a file transfer package, character conversion routine, or editing by a terminal configured for a different character set will destroy the scope of your source.

All of the languages you mention have weaknesses in critical business needs where Cobol is the strongest.

It works on machines that can hotswap any piece of hardware, and degrade gracefully if a processor dies. Reliability is everything when working with billions of dollars.

Those machines also support ridiculously large I/O speeds; if you can t handle a day s worth of transactions in real time, you re out of business.

It s been a stable language with very few deprecated bits since 1985.

The code isn t easily ported to another language, because developers didn t "plan" for that to ever happen. Moving the code that s powering systems today to another language is a risk and a very large cost.

Reliability counts for something, and COBOL has it in spades.

Why did it catch on?

It was heavily pushed by IBM. This was a great help for Fortran and COBOL, although not PL/I.

It was available very early on, first appearing before 1960.

It was a lot easier than using assembler, even IBM System/360 assembler (which was a very nice one for business processing). It picked up a lot of people trying to do better than assembler.

It was a very good match for common business computing practices of the time. It was very good at accepting input, doing minor transformations, and spitting out reports. (It still is, for that matter, but businesses have far more diverse needs nowadays.)

It had some special features, such as decimal arithmetic while keeping track of decimal points, and record data types, that worked very well in business.

Many big companies, especially banks, have complex systems written in COBOL, which just simply work. Rewriting and designing such systems is observed by many such institutions as being a waste of resources including time and money. There s also the risk that certain requirement-specific features may be lost along the way. Hence the age old expression, if it ain t broke - don t fix it.

I worked ao c , c++ and java too. all are advance n having grafical feature. But when matter of Computing comes, means no hard works only business calculations and speculations. no one beat COBOL in efficiency.. and Huge data procesing, Prossesing for a day or more then a day .. in Java or other language !!! forget. its only cobol and mainframe.

1. the bleach of security. there is no bleach for last morethan 60 year in mainframe.
2. simplicity of code to handle in emergency or showstoper situation.
3. hey use front end in java,vb.net all, but for data keeping the rely on DB2.so cobol became must.

its all resons why leading banking firms thinking 10 time before migrate from mainframe to other.

[Vendor Post - but not necessarily the vendor s official statement]

There is certainly inertia, an install base, and risk of change are very valid reasons, but I would say there are good reasons within the language itself. If you want to do batch processing of large sets of data records or want to do financial calculations then the definitions of record layouts and numeric data types are better than any other language.

As NealB describes in his post, I ve spoken to users whose natural environment and expertise is Java, but they keep the core logic in COBOL because it s the best tool for the job. They liberally mix Java (primarily for Unicode string manipulation and systems integration) with COBOL within the same application. If they compared the amount of code to do the same work in Java it just didn t make sense. Alex Turner has posted some great examples on another website comparing typical business functions in COBOL with Java.

Cobol was invented to allow people who knew nothing about computer to write programs. This is exactly the kind of bad idea upon which Business, particularity American business thrives.

Good software requires high skill and good tools some of which will actually require real knowledge and understanding to use at all let alone well. High Skill levels tend to demand high pay, thus the search for the sliver bullet continues and high skill is actively discouraged. Don t believe me? Try these links

http://userweb.cs.utexas.edu/users/EWD/transcriptions/EWD12xx/EWD1284.html