Hand-coded machine language gave way to assemblers that in turn were overshadowed by higher-level programming languages. These days, people are scrambling to find COBOL programmers and even IBM is offering free COBOL training. Part of this initiative is to address older systems in government that are now stressed or need modification to deal with a higher load or new procedures to address the current pandemic.
What has been interesting is reading the comments regarding this issue, as well as the responses like that from IBM. Often it goes like this:
- That language is ancient, no one uses it.
- We could do it better in XYZ language.
- Anyone can learn COBOL.
The first compiler I helped develop was COBOL. The compiler and its matching interpreter were written in BASIC, but that’s another story.
Which is why my typical response to these types of comments is :D. LOL. LSMH. ROFL. LMAO. LQTM. LOLZ.
My laughter needs to be put into context.
Most of these disparaging comments are probably made by those who don’t know the history or think about certain aspects of why COBOL remains so successful even when not in the limelight.
Keep in mind, COBOL was initially developed by in the late 1950s, so its age has now reached into the sixties. It’s one of a number of languages that are still around or have had major influences on the programming languages in common use today. One of these is FORTRAN, which is still being used as well, though not in business applications where the current COBOL snafu is taking place.
Algol is the other major language of the time. It has evolved rather than maintaining a continuous presence like COBOL and FORTRAN. Languages like C and Ada evolved from Algol. Algol was essentially the C equivalent for Burroughs mainframes. I worked with both early in my career.
Ada showed up in the 1970s along with C. C++ showed up ten years after C was up and running. Java and Javascript appeared at the end of 1995 making it 25 right now. Rust is not even a teenager popping up in 2010.
Age is a State of Mind
This rough timeline explains why I find it humorous that many discount COBOL as old and decrepit. That might assume COBOL from the 1960s is the same one used today or might have been used on platforms that are only a few decades old. Current COBOL compilers and systems work with the latest databases and backend websites, and they support object-oriented programming.
If you want to read about many of the languages used in the past and present, then check out "Before C, What Did You Use?"
There’s also the issue of functionality and stability. Languages like COBOL, FORTRAN, and Ada, as well as C and C++, have benefitted from stable definitions of the language over time. This allows for long-term support that we’re all familiar with in the embedded space. Military and avionics systems are just like banking and business systems that need to run for decades. Languages that turn over new versions every few months would wreak havoc in these environments.
Still, for the current crisis, it’s a matter of dealing not only with a language foreign to many, but the applications are in a context that’s also different. COBOL applications are likely using things such as ISAM and JCL that someone more familiar with Javascript, REST, and HTML will not have a clue about. Learning about those interactions is critical to supporting the applications.
Likewise, documentation, bug management, and source code control may or may not exist or match what’s currently in use for other environments. These types of issues make learning COBOL seem almost trivial.
Reexamining Legacy Systems
The exercise of dealing with legacy systems isn’t new nor is it unique to the business sector and COBOL. In fact, it’s quite relevant to the embedded space and probably not foreign to anyone who has been working in this space for a few years. It’s an issue for those who are new to this space or who haven’t been exposed to the requirements and solutions to this problem. New tools like containers and virtual machines actually make it easier to support older systems in addition to facilitating development and deployment of future applications.
Given our current situation with the pandemic, it may not be a bad idea to examine all aspects of development, support, etc., to see where there might be improvements to current development processes. Time is often the factor in considering or doing these chores and it may be what’s available at this point.
Keep in mind that various tools have been designed for particular contexts, and they will often remain the best choice for those contexts. I find it a bit silly when someone starts asking whether to use strings or floating-point variables for monetary values. There’s a reason why a COBOL definition using PIC s99999v99 would be useful.
If you’re interested, Ada provides similar, very specific type definitions that aren’t possible with something like C. Ada also supports fixed point as part of its standard as well as bit-field definitions unlike the #defines or const definitions used in C.
I don’t plan on dusting off my COBOL background as it is about as old as the language, but some of you may. You might also want to see how it has progressed along with some of those other archaic languages like C.
