COBOL Turning 50, Still Important

Death Metal writes with this excerpt from a story about COBOL's influence as it approaches 50 years in existence: "According to David Stephenson, the UK manager for the software provider Micro Focus, 'some 70% to 80% of UK plc business transactions are still based on COBOL.' ... Mike Gilpin, from the market research company Forrester, says that the company's most recent related survey found that 32% of enterprises say they still use COBOL for development or maintenance. ... A lot of this maintenance and development takes place on IBM products. The company's software group director of product delivery and strategy, Charles Chu, says that he doesn't think 'legacy' is pejorative. 'Business constantly evolves,' he adds, 'but there are 250bn lines of COBOL code working well worldwide. Why would companies replace systems that are working well?'"

Comments

Re:Why replace it?

[artor3]

Learn COBOL, and you always will. My dad is a COBOL programmer for the NY state government. According to him, around 95% of their COBOL programmers are within 10 years of retirement. The youngin's (as he calls them) are in their mid to late forties.

If you know COBOL, you are absolutely guaranteed a job there.

Re:Define "working well"

[TheRaven64]

I think you mean final here, no? finally does something else.

Yes, sorry, final.

And it increased flexibility, reduced complexity and code size, and vastly improved maintainability.

Reducing code size is important for three reasons:

1. It means that a single human can understand more of the program at a time.
2. It means that there are fewer places to look for bugs.
3. It reduces instruction cache usage.

This last part is something I should probably have mentioned in the last post. Instruction cache churn is one of the biggest performance killers on modern CPUs. It is particularly instructive to compare C++ templates and Objective-C. In C++, your compiler will generate a new set of functions for every template instantiation (well, not quite, but close enough). In Objective-C, it will only emit one copy of a method and then use run-time lookups to determine how things work. The Objective-C solution to the problem is slower. You can generate lots of microbenchmarks that prove that it's slower. Except, somehow, the C++ program ends up being slower overall, because the Objective-C program can keep most of the code in cache, while the C++ program is constantly thrashing the instruction cache. If you run a couple of programs concurrently, each one gets even less cache usage, so you end up spending even more time waiting for main memory.

This is almost a corollary to your comment: it isn't slow until you test it in place. On a modern computer there are so many potential sources of performance issues that you can't always take a microbenchmark and generalise it. There are lots of cases where one option is slower when you do it once but faster when you do it a few million times, or faster when you do other seemingly-independent things. Microoptimisations are no longer a good way of ensuring that an entire program runs quickly.