For all new developments, the COBOL language is no longer relevant. But many also think that of Java. I do not think that’s the case. The problems that these languages are trying to solve are different. Java is still well suited to current architectures, while COBOL is not.
Recently, a discussion arose about why Java used int for arrays size (in case Strings has more characters than Integer.MAX_VALUE). One person identified this as being identical to the problem of the year 2038 (the year 2000 bug but for the C) and another one referred to the COBOL language.
The legacy of COBOL
Why do we think COBOL is dead, yet there are even more COBOL lines than any other language?
COBOL, Common Business Oriented Language, has never been considered a language at the forefront of innovation, except for one aspect: its ability to describe things very clearly and precisely. This is due to its design which was based on a language that is close to the natural English language.
Data types were allocated statically and specifically. If you wanted a floating point number, with 7 decimals, you would describe it as: PIC 999V9999999. The basic concept is to describe exactly what you want and that is exactly what you want.
In the same logic, the code was simple. You describe the program in terms of procedures or paragraphs. The executable code was as simple.
001000 * THIS IS A COBOL HOW
001010 * LOTS OF REALLY VERBOSE STUFF HERE …
001020 ADD LINE1 LINE2 LINE3 LINE4 GIVING SUB-TOTAL.
001030 MULTIPLY SUB-TOTAL BY TAX-RATE GIVING TAX.
001040 ADD SUB_TOTAL TAX GIVING TOTAL.
001050 * MORE REALLY VERBOSE STUFF HERE.
You can also use a less academic method to calculate the total, even in COBOL. The language offers advanced expressions like COMPUTE.
The power of COBOL
Remember: COBOL is a Common Business Oriented Language. It was before Big Data, before data science, and Machine Learning was like magic.
COBOL has been designed to provide business processing power. It means being able to explain things at a time when the most complex system was mechanical machines to add up.
For these people, it was easy to read descriptions, simply formulated, specifying what it should produce – add that to have such a result, multiply that number by another then add that number gives this result.
But today, the context is different. People are used to computers, their smartphones deliver more power and have more memories than the most powerful mainframes of the time. This has forged some confidence in the power of the machine.
People are also used to not having the same control abilities as before. For example, I had to explain to two senators how some of COBOL’s specific lines defined tax rules. Today, I will not have to show them the code anymore. Everyone is close enough to the concepts of programming.
The problems to be solved are also different. In the 80s, the code was designed around batch processing. Systems accumulated changes over a given time period (typically one day) and implemented each of these changes in a single run.
Today, systems respond to hundreds of thousands of transactions in real time. For example, credit card issuers can identify in a few seconds fraudulent use of a card, send a notification to a user whose card could be stolen. Trading applications must also react within a millisecond, and apply complex algorithms to make decisions.
I can understand that COBOL is appreciated for its simplicity in coding some of these algorithms. But I doubt that it is adapted to translate the most complex. They ask for abstraction that COBOL is struggling to provide.
You can always see this in action. Just look at your bank account. Updates are often done around midnight. This mechanism is reminiscent of old COBOL programs.
My first idea was to compare Java to Cobol – Java is now a 20 year old language – thinking it was becoming archaic. But it’s not the 32-bit indexes that make or break a language. The way language represents and simplifies a problem is its foundation.
COBOL has suffered over time because developers wanted, and needed to be able to write concise code to express very complex concepts. Java has also suffered – that’s why Scala and Kotlin in particular have revved up. Java is much more concise than COBOL, but compared to Scala and Kotlin, it is much more periphrastic.
However, Java, as verbose as it is, is not so expressive. On the one hand, it has certainly gained in features (such as lambda expressions) that reduce this verbosity while adding other functions. On the other hand, it is an object-oriented language from the beginning; which makes it an adequate bridge between the functional and the object.