Ask HN: Why did people switch from COBOL to newer languages?

13 points by asdfman123 ↗ HN
I realize COBOL is still alive and kicking, and there are a lot of banking jobs that still use it. It's probably much better than most people give it credit for.

However, what are the reason people mostly stopped building greenfield projects in it?

12 comments

[ 4.0 ms ] story [ 34.4 ms ] thread
Think back to when COBOL actually changed. This is when the PC was becoming more common. So people would tend to use whatever came with the PC. Basic was the most common language. If Apple and Commodore had opened up into a COBOL interpreter, it would have lasted that generation.

I am not sure why C took over from Basic. Perhaps it had something to do with speed or with control. I don't know if the same reasons would apply to Cobol.

C didn't take over from Basic. Basic was used by the end user because it was free with the machine. It wasn't used by that many software engineers. Most of the software made for the early personal computer (8-bit era) was written in assembly. Assembly was still popular on the 16 bit machines, but most software was written in Pascal or C.
Why would you assume it's better than people give it credit for?
Ignoring the question of its technical merits, a separate branch of devices started out without having COBOL. It didn’t have it because devices weren’t powerful enough to run a compiler, and because people buying those “toys” (more engineers than accountants) weren’t interested in running COBOL programs.

When microcomputers started being powerful enough, there was little pressure to port COBOL code because existing COBOL source code (mostly) was closed and mostly ran batch or networked programs (online transaction processing is the ‘AWS lambda’ of the 1960s) that nobody was interested in.

Also, (wild idea, but may have some truth in it) VisiCalc may have allowed accountants to implement what they wanted from those COBOL programs.

Finally, one could argue people didn’t stop creating COBOL projects. It’s just that new programmers, growing up using microcomputers, never started creating them, and those ‘new’ programmers soon hugely outnumbered ‘old’ programmers.

Same as "why did we leave C for JavaScript?"
True fact. I think young generation think that COBOL isn't as sexy as working with modern frameworks. Another reason is that COBOL historically hasn't been the most attractive option for young programmers as no one likes to spend the rest of their career doing maintenance work rather than any greenfield development.
That's probably the most insightful answer I've seen in a long,long time.

We tend to ignore the human side of the tecnology business. In fact young people usually wants to change the word, at least to find a pleace in the world for them.

There are a lot of support and maintenance positions available to junior developers, with a huge rotation because once they've learnt enough they want to build stuff.

COBOL might be a proven, old, technology... which means maintenance is important. New stuff must be build with a lot of legacy in mind, and you'll inherit legacy mistakes that worked and cannot be fixed unless you overhaul a huge amount of code.

That's not even sexy enough for senior, gray-haired developers; but helps pay the bills.

COBOL (at the time) cost money, C and other languages did not. COBOL was directed at mainframes (expensive, hulking behemoths), mini- and micro-computers could do much of the work (for small-to-medium offices) without needing the dedicated support staff and cost.

Banks and other big institutions continued using it (and many still use it) due to inertia. Even as they migrated from mainframes, but often by virtualizing them rather than outright replacing them.

Offices without that inertia introduced information systems when someone bought an inexpensive (relatively) machine and wrote a C or BASIC or other program on it to handle expense reports and other things that the corporate users used mainframes (with COBOL) for.

Mainframes required deliberate intent to purchase and use. They cost too much and required a full, proper, division. Local microcomputers within the corporate division required no cross-division coordination, and became "simple" line items in their annual or quarterly budgets.

Eventually companies start centralizing IT again, but by that time their software is all written in Java, C, C++, Perl, and other things so they build up server farms aimed at running that, not at running COBOL.

Why no greenfield COBOL projects? Because we don't have enough developers to do that, and deployment would be a pain. The infrastructure for deploying COBOL isn't present. Make an AWS for COBOL, and maybe people will use it? Probably not though. Also, no one knows it and the language has no compelling features to draw in new users.

It makes reports really well, but so does Perl and Python. It doesn't handle numerical work as well as Fortran (for those caring about performance) or numpy (for those not). And it has a strong cultural bias against it at this point.

  cost money, C and other languages did not
Only in the UNIX world, where C was a freebie. When I first got into C, pricey Microsoft C and MASM were needed for MS-DOS development. Turbo C, gcc, etc. came later.
Would it shock you to find out that Cobol developers make almost as much as Java developers? And I'm pretty sure they don't need to constantly learn a new version of the language every few years.
While true - you are generally tied to your companies implementation and business logic, with little chance of moving around. So once the system goes your skills can be obsolete