>> The next reason is readability. COBOL is known as a "verbose" language, especially when it's compared to a very terse language like C++. From a debugging standpoint, COBOL can be like reading a novel: In fact, I'd almost bet that, with a few variables thrown in, you could get arbitrary chapters from Game of Thrones to compile. Of course, all your favorite functions would die depressing, lonely deaths, but still…

In a way, this verbosity of which he speaks is the antithesis to the current 'Learn to Code' fad. And COBOL is a perfect example of a language that was intended to be so easy and intuitive to read and write, business people could do it (as it was promoted in the early years). COBOL has sections, paragraphs, and sentences, verbs and variables are nouns. Control flow is either via goto or 'perform'ing paragraphs or sections.

Awesome in theory, for simple programs, the idea that anyone can write/read it may even be true. But the devil has always been in the details. Logic in the perform/goto world quickly spirals out of control/comprehension, and for any non trivial COBOL application, there are multitudes of programs, flat files, indexed files, etc.

Not to mention the complexity of batch cobol (if you haven't lived the horror of mainframe JCL, I envy you) and wiring together green screens in the CICS environment are all very involved, the definition of platform specific.

>>The first reason is employability. As noted, there are still plenty of companies running applications built on COBOL. And not all of those applications are archaic: Since 2002, COBOL has had an object-oriented framework.

And most of them have off shored most or all of their development. One prominent local employer of COBOL programmers has a skeleton crew of COBOL developers after once employing thousands. Additionally, I'd have to see some stats that anyone has upgraded to the 2002 standard to believe anyone is actually using object oriented COBOL in production.

Having said all that, COBOL was designed in a time of scarce resources and does make excellent use of system resources. COBOL is close to the metal in a way that C is not; COBOL is more like verbose assembler than C. In COBOL all storage is statically allocated (memory allocation is possible, but not typical), and there is no call stack. This mean COBOL programs never experience stack overflow exceptions, out of memory errors, buffer overflows. Characteristics that make it 'safe' from a security and multi tenancy perspective.