September 20, 2008
NOTE: This article may be reproduced and circulated freely, as long as the copyright credit is included.
Last year, upon the death of John Backus, we looked back at Fortran, a half-century-old programming language that's still in general use. The October issue of Dr. Dobb's Journal resurrects interest in another language that's still widely used: COBOL. The article1 reminds us that
|"Billions of lines of new Cobol code are being written every year."|
and speculates that COBOL may still be an appropriate language for new Web 2.0 development.
From COBOL's birth that language has been the source of endless misinformation, and the latest article is no exception. Here are a few memorable myths:
We disposed of that one several years ago. Although that claim was widely accepted when COBOL was presented to the world, it became a joke as monster COBOL programs were seen as impenetrable nightmares.
Because its very name is an acronym that includes the term, it was natural to accept that claim without careful scrutiny. But we can search the language and its run-time support thoroughly and never find a tiny fraction of the support for business that's common in a modern spreadsheet processor. There's no built-in support either for frequently occurring data types or for common financial functions, nor does the language structure facilitate transaction processing. The sole innovation I can think of was the floating dollar sign in number formatting.
Actually the syntax, tedious as it is to code, is the least of the obstacles COBOL puts in the path of a good programmer. You get used to the syntax, or you can use a macro generator to expand it from a compact form.
It would take dozens of pages to cite all the real serious shortcomings of COBOL, but I'll mention a couple here:
In their zeal to produce an English like syntax COBOL's designers preferred the term "sentence" to "statement". And of course in English sentences are ended by periods. But the period in COBOL imposes multiple closure on all open conditional statements. Programmers would stare at nicely indented "structured" logic and wonder why it didn't do what appeared obvious. A premature period was often the culprit.
Critics used to complain that PL/I was too large a language, and indeed PL/I provided vastly greater functionality than any of its predecessors. But surprisingly a COBOL manual contained about the same number of pages as a PL/I manual. How could that be?
Instead of presenting facilities a programmer could use, the COBOL manual had to present dozens and dozens of special rules and restrictions. For example:
OCCURS) had to be specified as a literal constant, thus forcing you to repeat a "hard coded" value. Furthermore, you couldn't specify values for a table in the same declaration but had to use a
DISPLAY <value>statement will produce garbage if the value parameter is an internal numeric (
COMPUTATIONAL) data item.
MOVEof a group item will produce garbage if the source and the target fields don't have the same internal form (
COMPUTATIONAL), but moving a single item or
CORRESPONDINGitems will effect the expected conversion.
This is the new one from Dr. Dobb.
|"Developed in 1959 . . . COBOL is characterized by a verbose English-like syntax and a strict hierarchical program structure." (p. 16)|
The above is not only wrong, it asserts the exact opposite of a notorious COBOL deficiency. If there was ever a language that discouraged hierarchical structure it was early COBOL. The only thing remotely hierarchical in the language is the ability to specify group levels in a fixed record structure.
|The original COBOL offered no way to build a program out of parameterized subroutines.
data element used in the whole program was jammed into one common monolithic
Not until the COBOL 742 standard did the language support the
Furthermore, by that time the monolithic style of programming had become so firmly entrenched among COBOL programmers that hierarchical program structure was practiced by only a minority of programmers. Popular textbooks on COBOL programming, including many with the word structured in the title, ignored modular hierarchical program structure.
The Dr. Dobb's article urges us to keep an open mind. The latest version, featuring object-oriented extensions, may well be appropriate for some applications.
Programming in a limited language with lots of restrictions can be a satisfying challenge for a good programmer, but there is a huge difference between bad COBOL and good COBOL. Several years ago we looked at some organizations' COBOL coding standards and, with feedback from readers, concluded that many of them were misguided and even harmful.
A good programmer uses whatever tools contribute to solving the problem. If you find yourself using COBOL, use it well and produce well organized, well structured, maintainable programs.
1—Michael Swaine: "Is Your Next Language COBOL?", pp. 16-18.
2—IBM and others had earlier supported a non-standard
ENTER LINKAGE feature, but it was used mostly for calling
small utility programs coded in assembly language.
Last modified April, 2013
Return to IDI home page