COBOL: Completely Obsolete But Omnipresent Language

The programming language COBOL is a nuisance, something everyone wants to get rid of; however, I’m about to advise you to learn it. It might be a gold mine.

The IT world is a fast paced one where obsolescence is the rule and where things evolve so fast that any person who wants to understand it has to continuously learn and train. Languages, methodologies and technologies keep on changing, evolving to make programming easier, safer more robust and above all, faster. As to every rule, there is one exception.

In 1959, convinced that the English language would be more suitable for programming than machine code or the assembly language, Grace Hopper creates the first ever human-readable programming language that would survive for over fifty years: COBOL

COBOL, 55 years old and still in its youth, not ever thinking about retirement, has become a nuisance, something everyone wants to get rid of but no one has the courage to try.

Are we ready to replace COBOL?

Nowadays, 80% of financial transactions are made through COBOL programs and most of those programs have been written decades ago and have proven to be reliable, effective and efficient. To top it all most companies which are still using it have invested a lot of money in those systems and if it is not broken, why fix it?

So why would one want to change them? Well, it’s not Java. COBOL was created in an era where IT didn’t have the meaning it has today. A program was mainly designed to replace simple repetitive tasks such as retrieving data from a database, performing a couple of operations and generating a report or updating some other data. Today’s programs have to present a front-end to thousands of users, go through different layers of security, logic and quick data retrieving before accessing the back-end to ultimately alter data and send some information back to the user. Alternatively, a program can be a tool to design objects and buildings, communicate with your friends, frag your opponents, enhance your reality, you name it… The whole philosophy behind the conception of programs has changed so much in the last two decades that having such an outdated technology that almost no one knows anymore represents a potential danger. Only few people learn COBOL these days and even though those systems are not supposed to evolve much, there is always maintenance to be performed. But are we ready to replace it just yet?

Fast, robust and future-proof language

COBOL has been on the brink of death for years but its presence overall hasn’t changed. Not only are the cost to migrate from one technology to another huge but the choice of the replacing technology itself is a million dollars question. What better than COBOL to perform typical COBOL operations? While not designed to be an Object Oriented Language such as Java or C#, COBOL has slowly adopted some of their aspects, extending itself and its functionalities to a point where almost everything is possible. Everything with the exception maybe of creating user friendly or good looking Human-Machine Interface. In that matter, nothing has changed much since Hopper’s time. Many of us still remember the frustration of spending hours to get a simple screen with a couple modifiable fields and those who still use them must be dreaming every day to replace F5 and F6 by simple buttons…

But that was never the point; the point was to have a fast, robust and future-proof language.

COBOLs main contenders

The discussion is still opened as to which language could replace COBOL but here are some pros and cons to the main contenders:

–       Java is easy to learn, well spread and has a huge community of developers already but is rather slow compared to other languages despite the existence of some specialized compilers and massive improvements in the last few versions. It is also arguably still in its youth and the yearly evolutions and changes to the language don’t play in its favor. Not to mention the recent security issues.

–       C++ is fast, flexible and robust but it takes time to learn and understand and has what is maybe its biggest flow, potential memory leaks. Something COBOL and Java programmers have, almost, never heard of. By conception, it offers a lot of freedom to developers but that also implies few ready-to-use components and thus it’s less cost-worthy.

Let’s say that one day we manage to find a clear winner, another major problem will suddenly emerge. COBOL was made to perform all kind of operations in one block but we have learned throughout the years that modularity is the key to success. So if we replace COBOL itself by another language, we will also need to have databases and SQL, a front end and HTML, most likely a Business Process Management Software to externalize workflows… Basically, replacing COBOL programs means creating whole new ones.

The ultimate piece of advice

While it is possible to replace this aging language, this comes at such an extremely high cost that we can anticipate its presence in at least the next twenty years which brings us to the ultimate piece of advice of this paper: if you have the opportunity to learn it and enough motivation to write white on black interfaces, go for it. The pool of competent COBOL programmers is getting smaller by the day and the demand doesn’t change, meaning that this personal investment might reveal itself a gold mine.

Comments

6 responses to “COBOL: Completely Obsolete But Omnipresent Language”

  1. Nick P Avatar
    Nick P

    Poor alternatives. Both were garbage back in the day and are garbage today. C++ is fast and flexible but far from robust: great skill is required to write reliable and secure programs. Java is very verbose, uses a whole VM when a runtime can suffice, has too much influence by Oracle, and libraries are a bloated mess.

    To determine a replacement, we need to determine requirements. Ideal language will be productive, safe by default, perform well, be portable, easy to read, easy to train newcomers, easy to compile, and have a simple compiler + runtime or libraries for future proofing. Latter is for the event when company must move platform to new hardware or OS with no external support.

    Alternative 1: Pascal or Modula-3. My main recommendation. Wirth’s language family are all easy to learn, easy to compile, easy to read, easy to port/maintain and fast. Productivity might lower than some languages with syntactic sugar. These two have been used in desktop apps, server code, and even OS’s. Modula-3’s runtime supports GC. It’s GC or type system can be disabled where needed.

    Alternative. An industrial BASIC with IDE and community. There are several with basically same advantages as Pascal. I started in BASIC and even wrote a C++ compatible one that generated C++ code do I’d never have to code in C++. Worked great and fast compiles let me iterate faster.

    Alternative: Ada 2012. Ada has as bad a rep as COBOL. Yet, it can do everything from OS’s to concurrent server software with excellent built-in error catching, good performance, tiny (or zero) runtime, great portability, good maintenance, cross language development, and integration of diverse work like you haven’t seen before. NOT easy to learn, compile, or port. Good news is several vendors stay in market. Plus, SPARK Ada can prove critical stuff free of coding errors.

    Alternative: Python. Coverity said it had lowest defect count in industry. Language is very productive, safe, and easy to read. It’s several times slower than others on this list and would be harder to reimplement. It’s basically a slower, watered down, more readable, and standardized LISP. I’d make it my recommendation if it got near native performance, optional static typing, and an easy to build runtime.

    Alternate to watch: Julia. Ultra fast dynamic language great at number crunching and interoperability with C. Real macro’s too. One to watch.

    Out of time so I hope readers enjoy looking into these and how much better legacy code could be to work with.

    1. Perci Raymond Avatar
      Perci Raymond

      I started COBOL programming late 1970s and ended up doing it year 2000.
      I’m still available and interested in working in it.
      I can be reached thru my email address perfran9@yahoo.com.

  2. Bertrand Besnard Avatar
    Bertrand Besnard

    The main goal of this article is not to pretend to have a solution to the problem but to explain why it is so hard to get rid of COBOL.

    The alternatives I mention here are the two main contenders that are widely spread today and that’s the case because of many reasons. It does not, in any way, mean that I think they’re fit for the job.
    Having worked with most of the languages you mention (except Julia which I will read more about as soon as I find some time), I can safely say that none of them is fit for the task.
    Pascal and ADA are terribly hard languages to use and most programmers today find themselves lost when first introduced to them meaning they’re already outdated (or IT studies should be made different) and therefore not a good choice. Note that I don’t deny their value for specific use but it is my belief that the replacement of COBOL will have to be easy to learn/use/adapt since there are so many existing projects to replace.

    Python. While I appreciate the rigour needed to use it, you have to admit it is far from being fast enough to replace such a high performance language as COBOL.

    Once again, and as sad as it might be, there is no clear winner YET and that usually means that deciders will go for the option they know best: Java or C++.

    From a personal point of view: I started my IT studies with Java back in the days and while I’ve been an adept of that language until its 1.5 version, I am now slowly turning towards the whole .NET framework as i find the Microsoft way of thinking to be quite refreshing these days. If I had to do it all over again though, I would probably drop Java from my studies/experiences, for the very same reasons you mention.
    Learning and using Assembly, ADA, BASIC, COBOL and C are probably the best and most enriching things I did and I would recommend any one new to programming to at least try them, this offers a better comprehension of what we have today.

    Best regards,

    B.

  3. Aaron West Avatar
    Aaron West

    Some sort of integrated database and business-rules engine (sort of an 4gERP project?) written in Haskell might make a good replacement. Pick/M/MUMPS/multivalue databases were, I think, sold partly as an alternative to COBOL, and IBM bought it and renamed it? I think that’s a possibility, but I don’t like M/MUMPS, and most companies seem to be migrating away from multivalue/hierarchical databases. I knew a MAGIC/PC developer, and I suspect a 4GL development environment like that was more productive than COBOL, but don’t see it as an enterprise migration option. Python might not be too bad, but the practices of python programmers may be a bit too varied to come up with consistently clean and reliable and robust migrations with such a loosely-typed language. I would prefer Scala, F# or Haskell.

    Also interesting, though I wouldn’t call it a COBOL migration option… Wakanda is an interesting 4GL in Javascript based on some very old multivalue database (I think…)
    http://www.wakanda.org/
    (But I digress)

  4. Mik Avatar
    Mik

    What about GO? I am not a developer but I’d like to read opinions about it.

  5. […] predict it will remain a major language for the next 20 years, which is an amazing feat, given it was created at the very beginning of the computer age. So if […]

Leave a Reply