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?'"

Re:Oo, oo, oo! I know!

[Jurily]

Because the director of IT or whatever his title is will want to be able to put on his resume that HE moved a company from a "Legacy" and "Outdated" system to a modern "web based solution" that enables "greater productivity" among the workforce saving "millions of dollars". Now, he can put that on his resume and go for the CTO, CIO, or whatever jobs.

If and only if they're able to pull it off. It's also a nice way to end your carreer if you fail.

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.

Re:Oo, oo, oo! I know!

[blind biker]

This is not necessarily tied to MBAs as much as it's tied to corporate psychopaths - the ones most likely to succeed in the modern chaotic corporate world (especially in larger publicly-traded companies). They will lie, manipulate and use everything and everybody only to further their own interest. If the company, their workers or even the economy of the whole USA will suffer, they won't care one bit - no conscience.

Re:It's the maintenance, stupid.

[ralphdaugherty]

* I apologize for the profanity, but any program that can't change a fucking constant is a broken program. Or did they copy/paste 6.55 all over the place?

      Your comment is idiotic. Do yu think there was only one change to the minimum wage in all the decades that California payroll system was in production?

      There was a long thread on that system, and the real reasons that that California bureaucracy didn't want to modify the payroll system at that time was covered in the thread.

      I also provided a solution in the thread that didn't require modifying the system. The California thing wasn't about technology, it was about politics.

      There, I've wasted some more of my life on this idiotic issue.

  rd

Re:Define "working well"

[TheRaven64]

You are missing the point. When you pass something as a function parameter, it is either in a register, or in a bit of memory that is guaranteed to be in the cache and will hopefully (e.g. on modern x86 chips) be aliased with some hidden registers. The cost of accessing it is zero. If you put the data in a global, then you are accessing it via two more levels of indirection - read up on how your linker works - and so you are requiring at least one, probably two, more cache lines to be used and an extra set of load and store instructions for something that could otherwise stay in a register.