Why We Hate Cobol

"The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offence." (1968) -- Dijkstra

The CobolLanguage has the following bad attributes:

The above explains why I've never had any luck explaining Java or any ObjectOrientedProgramming concept to a COBOL programmer. Anything about defining a type, encapsulation or collections gets a blank stare back. [see TypeTheory, EncapsulationDefinition, JavaCollections]

Dijkstra lambasted a number of languages in How do we tell truths that might hurt? ACM SIGPLAN Notices. 1982 not just COBOL. He called FORTRAN "the infantile disorder", he called PL/I "the fatal disease", he said "It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration." and he said that "APL is a mistake, carried through to perfection." What do you think he would say about our modern languages? 

    [See Tompkins HE. In defense of teaching structured COBOL as computer science (or, notes on being sage struck). ACM SIGPLAN Notices. 1983.]
    [See Baldwin RR. A note on H.E. Tompkins’s minimum-period COBOL style. ACM SIGPLAN Notices. 1987.]
"The problem with being such an old language is that COBOL suffers from 50 years of accumulated opprobrium. Criticism of COBOL is often based—if it is based on direct experience at all—on programs written 30 to 50 years ago. The huge monolithic programs, the tangled masses of spaghetti code, and the global data are all hallmarks of COBOL programs written long before programmers knew better. They are not characteristic of programs written using more modern versions of COBOL." 
    [See Michael Coughlan. Beginning COBOL for programmers. Apress 2014. Page 14.]

I'd say that COBOL-85 was a failure due to lack of user-defined types. What good does it do you to have named functions ("subprograms") in your program with parameters, when you can't reuse types, like "employee?" The structured constructs (IF/END-IF, PERFORM/END-PERFORM are good, but COBOL-85, on the whole, falls short.)

I don't know if it was vendor specific but MicroFocus allowed user-defined types ages ago. Getting COBOL programmers to understand what they were about is another matter.

I question the long-term usefulness of entity subtyping in practical business applications. Could you provide a specific example? LimitsOfHierarchies

Every program, no matter how short, must have all four divisions. Someone write HelloWorld. In COBOL or C++ with MFC?

This has not been true for a very long time. See the examples at the end of http://www.csis.ul.ie/cobol/course/COBOLIntro.htm

Much of the evil in COBOL can be explained with code samples. For example, what does, for example, a counter class look like in COBOL-2000? Dunno. What would it look like in SQL?

Here is some COBOL code to compare to its Java equivalent. How evil is it? Which one is more easy to understand? COBOL version from Michael Coughlan. Beginning COBOL for programmers. Apress 2014. Page 3. 

    IDENTIFICATION DIVISION.
    PROGRAM-ID. SalesTax?.
    WORKING-STORAGE SECTION.
    01 beforeTax     PIC 999V99 VALUE 123.45.
    01 salesTaxRate  PIC V999   VALUE .065.
    01 afterTax      PIC 999.99.
    PROCEDURE DIVISION.
    Begin.
      COMPUTE afterTax ROUNDED = beforeTax + (beforeTax * salesTaxRate)
      DISPLAY "After tax amount is " afterTax.
Java Version from http://caliberdt.com/tips/May03_Java_BigDecimal_Class.htm 
    import java.math.BigDecimal; 
    public class SalesTaxWithBigDecimal? 
    {
      public static void main(java.lang.String[] args)
      {
        BigDecimal beforeTax    = BigDecimal.valueOf(12345, 2);
        BigDecimal salesTaxRate = BigDecimal.valueOf(65, 3);
        BigDecimal ratePlusOne  = salesTaxRate.add(BigDecimal.valueOf(1));
        BigDecimal afterTax   = beforeTax.multiply(ratePlusOne);
        afterTax = afterTax.setScale(2, BigDecimal.ROUND_HALF_UP);
        System.out.println( "After tax amount is " + afterTax);
       }
    }
COBOL does excel at what it's designed for, though - simple business applications running on systems designed before 1980. CobolScript was probably not the best spinoff for it.

There's an example of a COBOL HelloWorld at the TinyCobol page. http://tiny-cobol.sourceforge.net/docs/tiny-cobol-introduction-0.2/firstprogram.html It doesn't look too awful, but take a look at their next example...

I'm no expert but how about copy-statements with replacings? You can 'copy' a piece of code (from a so called 'copybook') in your program (somewhat like an include) and replace (literally!) a piece of text that (might) occur(s) in the 'copybook' with some other text. Stuff like this: 

  copy amountcomputer.cpy replacing '-' by '+'
  copy amountcomputer.cpy replacing 'varname' by 'var_name'
  copy amount_computer.cpy replacing 'end of the code.' by 'not yet the end...'
You get the point: what if someone changes the copybook (no type checking whatsoever of course). How about more than one replacing? How about conflicting replacings? Which is done first? 

Copy above-example replacing copybook by 'C header file'
Or conditional expressions. One can write: A > B and C which of course means A > B and A > C. But how about: A > B or F < B and C or D? You might think that the and-operation binds stronger, but that doesn't matter it will produce A > B or F < B and F < C or F < D (I think...).

You might hope people don't write code like that. Famous last words... -- AlexVanDenBergh

COBOL has major limitations, but certainly goes well beyond 1980, especially in combination with appropriate software, such as a database system. The COPY statement (especially the REPLACING option) was always weak. It is possible to write conditions that are "ambiguous" (in the sense that successive compilers from the same supplier interpret them differently), but such matters are uncommon.

Cobol is decidedly a LegacyLanguage; goodness knows the programming language design community has moved on. Nobody ever holds Cobol up as a shining example of goodness; nor does (hardly) anyone select Cobol for a project these days except when a) needing to do so to interface with/maintain an existing Cobol system, or b) a hypothetical IT shop full of Cobol programmers who know nothing else.

Flaming Cobol is like shooting ducks in a barrel; we might as well erect a page called WhyWeHateBrainfuck. Plus, there aren't any SmugCobolWeenies to annoy - which is why WhyWeHateLisp is such a more entertaining page. :)

Flaming COBOL is like shooting ducks in a barrel when you ignore the fact that COBOL is a domain specific language and insist on criticizing it for shortcomings that have little relevance to its target domain. It's like shooting ducks in a barrel when the criticisms levelled are mainly relevant to a version of COBOL and a style of programming that is now forty years old.

Re: "Columns Matter.....is outdated and cumbersome when used with modern text editing software."

Aren't there editors for column-bound languages (such as COBOL and FortranLanguage)? An editor designed for a CeeLanguage-style is obviously not going to be ideal for COBOL.

Focus on what you desire to have more of in your life, since your focus brings you more of whatever you put your attention on. ... WhatYouResistPersists. -- DonaldNoyes.2008

See also CobolCausesBrainDamage, BrainDamage, HadToUseCobol

CategoryRant

EditText of this page (last edited April 30, 2014) or FindPage with title or text search