O Cobol, Cobol! wherefore art thou Cobol?
Programming language popularity has been in the news again and as always Cobol is nowhere to be seen in the rankings. Even back in the day, when people in the know generally considered Cobol to be the most widely used language it often failed to appear, or appeared very low down, in language rankings. I think Cobol’s unrepresentative rankings occur because users of Cobol are assumed to hang out in the same places as users of other programming languages. The letters bo in the name is the clue, business oriented people are not usually interested in technical stuff and tend not to read the magazines (and these days web sites) that users of the other popular languages read.
Cobol is very business domain specific and does not contain functionality that makes it a reasonable choice for writing applications in other domains (it is possible to write a compiler in Cobol, for instance the Micro Focus compiler is written in Cobol). It has very sophisticated languages constructs for handling data having the most convoluted formats imaginable, essential in the business world which has to process data whose format has evolved over the years into a tangled mess (developers have to deal with spaghetti code, business has to deal with spaghetti data formats). Cobol’s control flow and code structuring facilities are primitive (all variables are global and the perform statement is very similar to the gosub statement found in Basic’s that are line number based) because business data processing tends to be relatively simple and programs to handle them are generally small (the large Cobol programs of legend are invariably made up of lots of small programs run in series with complicated data format dependencies between them).
I started to realise just how different Cobol is when working on my first Cobol code generator (yes it was written in Cobol). If a processor has lots of registers it is usually worthwhile to dedicate one to holding the value zero (of the 32 registers supported by most RISC processors, often only 31 can hold different values, one is dedicated to returning zero when read from and ignores any value written to it), in the case of Cobol it is considered worthwhile to dedicate a register to hold 0x20202020 (four space characters) rather than zero.
Is Cobol still the most widely used language today? No, I don’t think so. Business people love spreadsheets which means developers have switched to writing pre/post data format processing code, previously in Cobol, in Visual Basic (to convert input data into a form accepted by the spreadsheet and then print the results of the spreadsheet calculations in a presentable format); this Visual Basic source can often have a Cobol-like feel to it. This spreadsheet usage also resulted in the comma separated list becoming a widely used format for data representation, eroding Cobol’s unique selling point of sophisticated input/output data format processing.
What does language popularity mean? Does using a language you don’t like count towards it being popular? There are several languages I like and very rarely get to use, does this mean I don’t get to contribute to their popularity?
In these tough financial times the number of job adverts requiring knowledge of a specified language is probably of more interest than number of posts to web sites. One job search site lists 3,032 Cobol jobs and counting job ad hits for the top languages listed in a recent popularity poll puts Cobol at the bottom end of the cluster of highest ranked languages.
On mainframes I think Cobol is likely to still be No. 1; it is probably impossible to replace the dominant language in a niche market.
Java is the COBOL of the modern era. IBM made a commitment to that language, many years ago, with one language being able to target multiple hardware platforms.
My current gig involves creating intranet web applications for a company with a long-running commitment to RPG. We still have to maintain the old stuff, but the new stuff is all Java.
20 years from now, Java will be enjoying COBOL’s current amount of installed base and lack of current interest. COBOL will still be around, but disappearing at a decaying, diminishing rate, asymptotically approaching zero.
The only way to slay that particular beast is code generation systems which effectively parse the COBOL, generate some kind of intermediate format which can be proven to cover all of the requirements (and expose any unknown-yet-satisfied requirements) and generate code in a newer language which satisfies all of the requirements.
The “unknown-yet-satisfied” part is critical. The documentation of requirements NEVER keeps up with the actual coding to satisfy requirements. That’s a large part of why companies aren’t replacing their existing piles of COBOL (or RPG, for that matter) with newer code, more easily maintained by the younger crowd of developers.
That, and the fact that beancounters are pathologically opposed to spending money on maintenance.
More and more “new generation” developers think that online solutions (cloud computing) is dominated by Java… well, they’re wrong. Underneath those Sass codes are Cobol modules or classes that is being called by Java programs, and why Cobol? Because the language is very much the soul of the back-end data processes… and definitely it cannot be easily be replaced, but instead the Cobol language provided a link between these two language (Java/Cobol) to work together. And so history will tell us that both languages are doing the cloud computing of today!
For the last few months (today is March 2014), I’ve seen many websites dealing with business operations under pure-Cobol backend solution… coupled with PHP, ASP.Net and HTML technology related platform (jQuery/Ajax/CSS3/HTML5). Even mobile browsers are emerging under a Cobol umbrella. With this trend I do not think everyone could see Cobol will go away in the future.
Long live Grace Hooper!