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]


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?

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?

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. :)


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 February 13, 2014) or FindPage with title or text search