(Throughout this node, Cobol referrs to the modern language, standardized in the 1990s, and COBOL referrs to the unstandardized language that goes back to the 1950s.)

Every language has a domain of competence: That group of problems that language can solve more concisely and with less work than any other language currently in existence. Cobol's domain of competence is business problems, especially business problems that deal with large numbers of records and large amounts of money:

  1. Its mathematical model allows a level of control over the precise format of the number unheard-of in modern programming languages. This is required because people get quite irate if their paychecks or bank accounts are miscomputed due to a floating-point rounding error. Fixed-point and strict control over rounding rules is essential, and no language provides those features like Cobol.
  2. Its I/O model is completely record-oriented. This is utterly unworkable when you want to write a general-purpose text editor, but it's a godsend when you need to plow through millions of payroll records to compute FICA withholdings. This record-orientation dates back to the punch card era, but it maps well to how banks and other large corporations actually work.
  3. It works on the machines banks already have. No one was ever fired for buying IBM, and IBM mainframes (the big things running MVS, VM/CMS, and OS/400 in the back room) provide very good native Cobol support. OS/400 even provides a native database for your Cobol programs to get records out of. (Besides, if you aren't programming in Cobol you're liable to be programming in RPG, and that's nobody's idea of a good time.)

The downsides to Cobol are that it was once called COBOL and it really doesn't have any other domain of competence. I'll take these in turn:

  1. COBOL is one of the earliest high-level languages. Its immediate ancestry consists of autocoders, programs that are barely a step above macro assemblers, and very little was known about writing readable programs in those days. Couple that ignornace with the severe limitations of mainframes in those days and you end up with abominations like the ALTER verb and a complete lack of data encapsulation: Like the BASIC dialects that haunted microcomputers in the 1970s/1980s, every variable in a COBOL program is a global.

    This wouldn't be so bad if it wasn't for the prevalence of legacy code. There is a huge amount of really old COBOL software that strongly resembles Cthulhu: Leave it sleeping in the deep and all will be well, but wake it up and you will pray only to be eaten first. Suffice to say, future modification wasn't the foremost concern on the original authors' minds.

  2. Cobol is horrifically bad at anything that doesn't involve performing simple arithmetic on large numbers of fixed-format records. Its ability to finely control data types (not just numbers) means that the programmer must finely control data types, leading to either wasted space or unavoidable truncation. Its record-orientation makes it impossible to read unstructured files, like HTML documents or plain text files. Its atrociously ugly syntax makes it painful to read and impossible to write with real concision: There are no one-liners in Cobol. (Ironically, its syntax is horrible because it was meant to be easy to read. The designers thought an English-like syntax would enable non-programmers to write software, ignoring that fact that the difficulty of programming has nothing to do with syntax.)

    Cobol is not the language for most kinds of new software projects. It is a good language to keep using if the program has been running just fine since the Johnson administration. It is a good language to use if you need to write a new financial package and can't buy one from a software company. Beyond that, however, stay away.

Cobol and COBOL will be with us for a very, very long time to come. COBOL has outlived the structured programming, object-oriented programming, and aspect-oriented programming crazes, and it will outlive the extreme programming craze in due course. It has seen the rise of the Internet and the Web and the fall of IBM as a hardware company. (IBM still makes hardware, but it's primarily a consulting firm these days.) It will haunt our dreams until we die.