"The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offence." (1968) -- Dijkstra
has the following bad attributes:
- EverythingIsAMove -- Over 90% of a typical Cobol program will be MOVE, IF, and GO TO verbs, because Cobol is an English version of assembly language, which has the same ratio. Look at the output of a Cobol compiler and you will see a one-for-one translation. The semantics of what the MOVE really accomplishes remains in the mind of the original programmer.
- EveryVariableIsGlobal? -- Variables are shared throughout entire programs (no scope); variables are shared between programs using global Linkage Area; see GlobalVariablesAreBad.
- EveryVariableIsAStringOrNumber -- There is no support for defining AbstractDataTypes (ADT) or objects (until recent enhanced versions)
- MoveDoesSecretStuff? -- Many casting and transformation possibilities hide behind every MOVE verb, based on the type, size, REDEFINES, CORRESPONDING, and COMP options. Variables can redefine and rename each other: change one variable, you've changed another. This corresponds directly to assembly language concepts (DS and DC on IBM mainframe assembler).
- EveryProgramIsLong? -- Sub-program capability exists but is rarely used
- DataLayerIsNotSeparate? -- The Program Division contains direct reference to the physical name and size of database fields; this information is repeated in many programs, making changes very time consuming
- Reserved words -- Long list of common words that cannot be used as variables (longer than CeeLanguage, CeePlusPlus, JavaLanguage, PerlLanguage...)
- Not very portable -- Petty differences between implementations (like C and C++)
- Not available for certain environments.
- EverythingIsLowLevel? -- Related to EverythingIsAMove. Cobol provides a very small set of functions in the standard language definition. It is difficult (and rare) to create shared subroutines to raise the conceptual level of the programs.
- Oververbose syntax -- See SelfDocumentingCode
- IF statement uses a no-op statement called NEXT SENTENCE, usually as an attempt to avoid NegativeLogic?.
- IF ends with a dot (period character) (though, an ENDIF verb has been added in Cobol-85). Move a dot in a IF statement until the program compile and have lot's of fun watching your fellow programmers hunt this bug.
- Columns Matter -- An archaic descendant of punch cards, the notion of columns 7 being a star for comments, 8-12 for major divisions and 13-72 for normal code is outdated and cumbersome when used with modern text editing software.
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.
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 Micro
Focus 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
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
You might hope people don't write code like that. Famous last words...
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
- But BrainFuck was intended to be funny.. Cobol was intended to be serious. Or maybe CobolWasAnAprilFoolsDayJoke?
Plus, there aren't any SmugCobolWeenie
s to annoy - which is why WhyWeHateLisp
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.
See also CobolCausesBrainDamage