What purpose does this ancient programming language now serve?

New applications still being coded in Cobol!

©Conrad Weisert
September 8, 2015

NOTE: This article may be reproduced and circulated freely, as long as the copyright credit is included.

"A 2012 survey found that 48 percent of businesses and government organizations rely heavily on COBOL, compared to JavaScript's 41 percent, Java on 39 percent, and C# on 26 percent. What's more, over one-third of those surveyed said they planned to develop new applications in COBOL in the future."— Andrada Fiscutean for Central European Processing | August 12, 2015

We may wonder about that "survey", but there's little doubt that some organizations are continuing to rely on a programming language that was already becoming obsolete a half century ago.

It's not Cobol's age that makes it unsuitable for twenty-first century applications. Other languages from the 1960s and earlier1 have held up well and are still effective choices today. Cobol was a crude, weak, and error-prone language when it was brand new, inflicting huge costs upon software development and even more upon ongoing maintenance. Programmers who were active in the so-called "third generation" era (ca 1968) recall those mysterious ABEND codes accompanied by hexadecimal memory dumps from Cobol programs they thought had been thoroughly debugged. Frustrated managers remember the monolithic monster programs that were reported to be "85 percent coded" and would surely be ready for testing next week.

Although programmers find today's Cobol greatly improved over the crude language their grandparents struggled with, too many programmers still retain the expensive habits from Cobol's early days, especially monolithic organization2 of huge programs. Early Cobol's traditional programming style has been passed down through generations of mentors and textbooks.

Of course, it's possible for a skilled programmer to develop a decent program in Cobol. But in the absence of enlightened textbooks and courses emphasizing modular structure and good practices, high-quality Cobol programs remain rare. Why bother?

For more background and details on Cobol programming see:


1—For example Lisp (1959) and PL/I (1963) continue to serve their intended scopes well.
2—Some Cobol partisans, including a few very well-known "experts", continued to insist that parameterless
PERFORMed paragraphs bound to specific data items constituted adequate modularity.

Minor updates December 28, 2015

Return to IDI home page
Technical articles