Programmers aren’t the limiting resource. Learning a new language is easy compared to all the domain and program-specific stuff you have to learn when starting at a new company, and people move to new companies all the time. You’re talking a language with 300 keywords versus a program with hundreds of thousands of functions. It’s not even close.

Hardware eventually wears out, and if there comes a point when they can’t get compiler support for the new hardware, they will migrate to a new language then. These types of hardware migrations are usually planned several years in advance. I once worked on a major rewrite prompted by a dot matrix ribbon supplier going out of business. My company bought out a bunch of the ribbon stock to buy us enough time for the migration. “Luckily” the old language had sufficient support to move to the new hardware at the time, but the rewrite was extensive enough that we may as well have moved to a new language.

Funny you should ask that.

My father is a COBOL programmer. Graduated from college, got a job at a large insurance firm. Worked on the same app for his entire career (the same physical mainframe for 30 odd years of that). Spent the last 4 years remotely teaching a team of new graduates in India how to write COBOL. He retired last year.

I wouldn’t count that as a “plan” or even a good business decision in the long term. But corporations aren’t renowned for making good long term technical decisions.

It is naive to assume that more modern languages are somehow preferable to older ones for a given problem domain.

Beyond the issues of risk and the immense cost associated with such modernization is the fact that many legacy environments have their own ecosystem, and have evolved symbiotically with it. These solutions are often the best elixir for a problem they actually contributed to.

IBM is not giving up on DB2/RPG any time soon. COBOL flat files are not going extinct in our lifetimes. This is a fact. And even if we could remove (insert demonized technology here) we would have to address a problem domain for which we may not have the correct tools.

Is it simpler to do a minor amount of maintenance on a system that works or reengineer something we likely do not fully understand?

For better or worse COBOL, VB6, RPG and the like are no where near dead.

Languages, such as COBOL, don’t require exotic hardware. The only resources that might run out are staff. But as long as there are money to be earned, people will learn necessary skills.

Some companies today are rewriting their systems into more fashionable languages – but hey, I had an offer last year from a bank which seemed to be rewriting from C++ to Java… So, to answer “how will they deal with this?” I guess for every imaginable approach there is at least one company putting it into action. From training new ranks of programmer-archeologists to rewriting everything over and over again.

How are organisations planning to replace dead languages?
In ways that are likely business secrets.

When I was last working for a bank they were facing 3 issues:

1. They had hired a new Core system programmer once in the last 20 years an all others were retiring
2. The language was more dead than Cobol.
3. The core system was on a mainframe, which are incredibly expensive to run, compared to say a cluster of a few dozen commodity machines.

I was now privy to the actual business plan to handle it (so I can’t break the aforementioned business secrets).
My team did come up with a plan to solve it, and implemented most of it.

We built a tool which would translate from the aforementioned dead language,
into Java.
The tool we made generated fairly awful java. Mostly because work around for not having GOTOs, and also for the existence of Reentrant Functions, and a few other quirks that have not made it into modern languages.
The java it made was awful, but now it could be replaced module by module as new/changed functionality was required.
The translation tool was written in C#, making use of ANTLR.

The other side of the tool was in Java having implementations most of the operators and datatypes from the dead language.
Which included having to implement a virtual memory layer since Unions and pointers were sometimes used.

After we were mostly done, we cam to the conclusion it would have been better to not translate into Java, but into C++, because C++ still has alot of those features that haven’t made it into modern languages.
Java was originally chosen because of the cheapness of Java VMs in some particular cluster product/architecture.

When I left this was mostly done. It would compile/translate any sample code you could find for the dead language. What it couldn’t do was the database layer. Which was handled with 3 layers of preprocessing on the source code in the dead language, and which needed to be replace with remote db connections instead of what ever interface you use on a mainframe to access the database on it.

I left convinced it would work. But I have no idea if it has been checked back out of version control since I stopped working on it. It could be they are using it today.

I suspect in the long term (which many now be the past), the larger banking group company that bought them 6 months before I started will gut there IT systems entirely, and force them to just use a thin shell infront of the parent companies systems.