''"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: * 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.'' [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? * Everything Is A Move -- "Cobol is an English version of assembly language"? Let's see the one-for-one translation of the INSPECT, STRING, UNSTRING, EVALUATE, SORT or SEARCH. * Every Variable Is Global -- unless you declare them inside a contained subprogram (ANS85 COBOL) - similar to a procedure or method. Variables are not "shared between programs using global Linkage Area". The LINKAGE SECTION is used to define the parameters passed to a subprogram. Items defined in the LINKAGE SECTION of a subprogram are only visible in the subprogram. * Every Variable Is A String Or Number -- true as long as you ignore the version of COBOL defined in ISO2002. * Every Program Is Long -- "Sub-program capability exists but is rarely used" at least not in forty or fifty year old COBOL programs but how about COBOL programs written in the last ten years? * IF ends with a dot (period character) -- this used to be true thirty years ago but since ANS85 COBOL and the introduction of END-IF, END-EVALUATE, END-PERFORM etc COBOL's scoping is probably the clearest of any language. The period can still be used to delimit scope but the dangers of this were recognized by Howard Tompkins in 1983 and most modern COBOL programmers now adhere to the minimum period style suggested by Robert Baldwin in 1987. [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.] * Columns Matter -- "As of the ANSI 2002 standard, a free-format source code format is defined where source code lines can be up to 256 characters long with no fixed meanings assigned to specific column ranges." - ''OpenCOBOL 1.1 Programmer's Guide Page 1-11.'' In many COBOL compilers, adherence to these formatting conventions has not been required for many years. The last time I observed the column restrictions was in 1979 for programs submitted on punch cards to the DEC PDP 11/70. "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 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?'' 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. * Recent surveys show that new development in COBOL is still going on. In a survey of 357 IT professionals undertaken by ComputerWorld in 2012 53% of responders said that COBOL was still being used for new development in their organization. Asked to quantify what proportion of new code was written in COBOL 27% said that it was used for more than half of their new development - http://www.computerworld.com/s/article/9225099/Cobol_brain_drain_Survey_results. * The ComputerWorld survey 2012 also reported that when compared to languages such as Visual Basic, C#, C++ and Java, respondents rated COBOL better or the same for characteristics such Batch Processing (82% better & 12% same), Transaction Processing (65% & 24%), Handling business-oriented features (55% & 21%), Run-time efficiency (54% & 33%), Security (39% & 38%), Reporting (45% & 37%), Development cost (39% & 32%) Maintenance cost (43% & 29%). The only characteristics where COBOL scored worse than these other languages was Ability to hire programmers (55% of respondents said it was worse) and Agility (45% of respondents said it was worse) - http://www.computerworld.com/s/article/9225099/Cobol_brain_drain_Survey_results. * The CAST Report on Application Software Health (CRASH) 2011/12 found that COBOL had the lowest technical debt (defined in the report as “the effort required to fix problems that remain in the code when an application is released”) of any mainstream language, whereas Java-EE, averaging $5.42 per LOC, had the highest - Executive Summary—The CRASH report, 2011/12. CAST. 2012. http://www.castsoftware.com/research-labs/crash-reports 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 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