5

I know that some financial organizations still use "dead" languages such as COBOL. I'm wondering what will happen in the future, when almost no one will program in those languages, and the maintenance of their systems will be a nightmare because there won't be any resources. (This is what I think will happen).

Are these enterprises currently building modern versions of their systems? If not, how will they deal with this?

|improve this question
  • 5
    There are companies which provide support, consulting and staffing for COBOL financial systems, which these financial organizations will contract with. These supporting companies will hire people and train them to perform the COBOL maintenance, even if these hires do not initially have these relevant experience. (Posting as comment since it is just my speculation.) – rwong Jan 8 '15 at 4:05
  • I don't think it really matters who does the hiring. – Maria Ines Parnisari Jan 8 '15 at 4:22
  • 1
    I don't thing that organizations are planning that much, and that far ... – Basile Starynkevitch Jan 8 '15 at 5:53
  • 21
    Umm, the latest revision to the COBOL specification was COBOL2014, which added a collections framework and method overloading among other things. That doesn't sound "dead" to me at all. COBOL2002 added OO (including generics; overloading was added in 2014), XML processing, Unicode, and a lot of other stuff. The language is still being developed as are several compilers, including the Open Source GCC-based GNU Cobol. – Jörg W Mittag Jan 8 '15 at 6:32
  • 6
    @JörgWMittag: "The report of my death was an exaggeration" -- Mark Twain. – martineau Jan 8 '15 at 12:01
21

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.

|improve this answer
  • 2
    Note, however, that there's a difference between "John is retiring, let's hire a new programmer, they can be mentored by the rest of the team" and "all our programmers have moved on, let's hire a team of newbies that have very little experience with the language, its idioms, and its idiosyncrasies". – mikołak Jan 8 '15 at 9:32
  • 5
    The latter is a highly implausible scenario in the kind of company that's still using COBOL. Such companies are typically large, with very large programing teams, and pay enough to make sure their programmers aren't tempted to move elsewhere for financial reasons. – Jules Jan 8 '15 at 9:58
  • 2
    @Jules: Not as implausible as you think. I was hired as an add-on to a three-man team. Less than half a year into the job, I was alone on the job, and still am, six years later. I told them a rewrite would be more efficient in the first year, and that I figure I could do it in a year and a half. By this time, I could probably do it in half a year, but the chance of them ever going ahead with that is close to nil. – DevSolar Jan 8 '15 at 10:31
15

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.

|improve this answer
  • 5
    Cool story bro - but in no way answered the question. Still, I liked it so +1... :-) – Robbie Dee Jan 8 '15 at 12:35
  • 1
    @RobbieDee The answer element is surely 'they can hire people that do speak COBOL to train others'. Which is an obvious answer, sure, but it is anecdotally backed up. And if the obvious answer isn't somehow disputed or acknowledged in the OP, it definitely needs to be said.. – OJFord Jan 8 '15 at 15:42
  • When I see this answer I smell of a COBOL course on MOOC ... complete with video lectures, programming exercises, grading and forums – rwong Jan 8 '15 at 20:09
  • As for the mainframe itself, IBM is now selling COBOL VM's so that you can run the old environment on other, newer generation IBM mainframes, many of them running Linux OS inside. – rwong Jan 8 '15 at 20:11
9

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.

|improve this answer
  • 6
    I suspect COBOL will outlive all of us... – Robbie Dee Jan 8 '15 at 12:54
5

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.

|improve this answer
  • 4
    +1 for "But as long as there are money to be earned, people will learn necessary skills." And because very few people graduate school saying "I want to be a COBOL developer", companies that need them have to offer a salary premium to recruit staff. Put enough money into it and you can get some people to do almost any otherwise less appealing job. – Dan is Fiddling by Firelight Jan 8 '15 at 14:49
2

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.

|improve this answer
  • 2
    "After we were mostly done, we came 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." -- Funny, that's what sprang to my mind two paragraphs up. :-D C++ is a sucker for versatility that way. – DevSolar Jan 8 '15 at 10:36
  • What kind of code base were you working on? Millions of LOC? I'm curious about at what size it makes sense to write a translator versus doing it by hand. – user25946 Jan 8 '15 at 16:05
  • @JonofAllTrades It's very handy when it's a lot of obscure code, which has been thoroughly tested. It's easier to make sure all of the transformations work as intended (and maintain consistency with automated testing) than to rewrite and test everything all over again, especially with the kind of complexity present in old codebases of these kinds of applications. – Luaan Jan 8 '15 at 16:15
  • @JonofAllTrades I couldn't take much of a guess. Somewhere in the high hundreds of thousands to single digit millions. The codebase was decades old and had continously had a large team of developers assigned to it (or rather farmed out to the other teams who needed changes made to it for their systems). It did infact have automated tests. Though they were added using another tool my team made only fairly recently before this project, so the coverage was quiet variable. What it did have (as Luaan gets at) decades of man-years of manual testing from QA, and proven production record. – Lyndon White Jan 9 '15 at 1:15
  • 1
    @kai It was definitely a stimulating challenge. Not nightmarish at all. Great fun. It was the kinda project I would bring up if anyone ever asked "What is the coolest thing you ever worked on." – Lyndon White May 4 '16 at 12:29

Not the answer you're looking for? Browse other questions tagged or ask your own question.