September 8, 2015
NOTE: This article may be reproduced and circulated freely, as long as the copyright credit is included.
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:
PERFORMed paragraphs bound to specific data items constituted adequate modularity.
Minor updates December 28, 2015
Return to IDI home page