COBOL is still (heavily?) used for financial computing. It is an old language, and AFAIK most programmers hate, or at least dislike, COBOL. This brings a question: is the only reason COBOL is still used that legacy software uses it, or does it have any real advantages over other programming languages?
Just curious.
It's mostly legacy now. Many critical business systems are still in COBOL simply for the fact that they are so big and integrated that the cost of rewriting doesn't seem worth it. Writing a new system in COBOL is probably not feasible anymore, as most COBOL developers are so scarce that they can pull in a considerable amount of money for the specialized skill (similar to a Foxpro developer now). There are few to no reasons to keep a COBOL app around, but unfortunately the common reasoning is when the COBOL app is already in-place, trusted, and tightly coupled with other systems to where it's near impossible to replace. That reasoning is exactly why it should be replaced before it gets to a situation where the only hardware that runs the app has to be custom built from Ebay parts from the 80/90s.
COBOL is still (heavily?) used for financial computing.
Is it?
It depends on what you call financial computing. If you call all the code that is run by financial institutions yes, it probably is. Most have business rules written in the 60s and 70s. The risk+cost of upgrading systems like this to a new environment is not worth it. I doubt that there is anyone out there writing new COBOL code. There are COBOL compilers today that integrates into the .NET stack, for example. Often there are tools for integrating and leveraging legacy applications into modern software stacks but those tools are often unknown to people who doesn't have to use them, since it's a very niche market.
Now if you call financial computing something more akin like software for quantitative finance I never heard about someone using COBOL. C++ is way more common, along some niche languages like k, an APL derivative.
COBOL mostly sees legacy use now. It's user base is slowly dwindling by attrition, as no new applications are being written and old ones slowly, but surely, are phased out.
Most COBOL systems which could quickly and cheaply be replaced, have been replaced already. The ones which have not, continue to become more and more expensive to repair or replace, but cheaper and cheaper to maintain relative to newer systems - they run well on cheap, out-dated hardware, and, after many years of service, are no longer showing any new bugs. Most bugs have either been fixed, or have longs standing traditions which fit as work-arounds. Maintenance typically has been reduced to one or two specialized employees, who, after a long time working on the system, know it more intimately than you can imagine.
Even from a technical perspective, there are usually some sound reasons to keep the old systems around. They are relatively stable, have been mostly bug-fixed, and are well known/understood by the end-user.
You'll see the system eventually being replaced, though. Typically this move comes from the business side of things:
wonder what you meant by "Most programmers". I work in a large IT shop on the same floor as cobol programmers, Java programmers, .NET programmer (in singular), old style VB programmers. There is no hate or dislike. cobol is a language like any other programming language- people programming in cobol do so because it's a job to them no different than programming in java or driving a truck. Contrary to popular conception in the US there is a lot of cobol continuing to be written, only most of it is in India where every day new Cobol programmers start work.
I think the reason why not too many net new systems are written in Cobol is because the kind of systems that cobol is suited for (large volume file processing) are all already written. Very few new large corporations get created these days. And the ones that do might be outsourcing things like payroll and benefits to companies that run legacy cobol systems.
With 20 years of COBOL experience, on three different mainframes, it is my humble opinion there are few true COBOL programmers and instead there are IBM programmers, Sperry (Unisys 2200) programmers, Burroughs (Unisys MCP) programmers, and Tandem (HP NonStop) programmers. In a showing of respect to them, I must also mention the presence of HP 3000 programmers, BULL programmers, and DEC programmers.
COBOL runs on big iron boxes, for the most part. Perhaps the only true COBOL programmers, by my own standards, are those writing COBOL on a UNIX box. Wow, I am going to hear about this.
Because the hardware is the central piece, most programmers who write COBOL identify themselves by the hardware on which the code they write runs. Over the years, listening to other programmers tell me about the merits of Sperry, Burroughs, or Tandem, I have often wondered what kind of warfare would ensue if I were to round them up and place them in a room together unable to leave until they agreed upon one hardware platform for all COBOL. I did not mention the other platforms because I have never worked on them.
I have met and talked with many IBM programmers, and they will refer to themselves as COBOL programmers. However, if one engages them in conversation, they quickly begin referring to IBM specific procedures and tools. Given the hardware-centric nature of COBOL, this is very understandable, for all hardware platforms.
Because COBOL is usually tied to a very expensive piece of hardware, as long as that piece of hardware runs the COBOL programs compiled on it then there is no strong desire to migrate from COBOL for migration’s sake. However, with an aging population of COBOL programmers, migration is inevitable.
Since all of the big iron boxes running COBOL will also run Java, Java is the natural path of migration away from COBOL. Code can be converted, particularly now in a down economy, for a rather economical price. Once there is no COBOL, only Java, on that big expensive piece of hardware, then someone higher up in the organization is going to start wondering whether it is possible to move the Java code over to some other much less expensive piece of hardware.
IBM, Sperry, Burroughs, and Tandem programmers know this, so they will likely NEVER offer up the idea. It would be a sacrilege for some.
A large portion of the core code in PeopleSoft is written in COBOL.
