Why is COBOL still a preferred language in the business world?

Question

Even though we have languages like C++, Java, Python etc., why is COBOL still a preferred language in the business world?

EDIT:

Why was it so popular?

Sorry for not creating a separate thread for this question.

Answer 1

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.

Answer 2

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.

Answer 3

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

Certainly inertia, 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 maniuplation and systesm 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.

Answer 4

Why did it catch on?

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

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

It was a lot easier than using assembler, even IBM 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.

Answer 5

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 IO 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.

Answer 6

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 evolving but remaining backward compatible is a strong reason for a business to invest in it; the tco is reduced because there is no need to re-write.

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

Answer 7

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).

Answer 8

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 doesn't need to be internet-aware, it just needs to do what it does well -- accounting mostly.

FWIW, C++ is an abomination. C was an ok substitute for people too lazy to learn assembler, but tacking C++ on was just silly. That is the easiest language in the world to shot yourself in the foot with. Do you want your 401k balance dependent upon someone kids ability to remember the difference between "." "->" and "*"?

Java is good, save, 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.

Python? After 40 years of headaches with programs/shells/compilers puking all over the difference between spaces, tabs and end of lines some retard decides to make a language that delimits scope based on spaces, tabs and end of lines? WTF? That will never be a serious candidate for the enterprise where dozens of file transfer packages over dozens of hardware platforms in dozens of countries with dozens of different character sets operate. Here is a nickel kid -- go buy yourself some brackets.

Answer 9

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