Editing COBOL (section)

== Reception ==

===Lack of structure===
In the 1970s, adoption of the [[structured programming]] paradigm was becoming increasingly widespread. [[Edsger Dijkstra]], a preeminent computer scientist, wrote a [[letter to the editor]] of [[Communications of the ACM]], published in 1975 entitled "How do we tell truths that might hurt?", in which he was critical of COBOL and several other contemporary languages; remarking that "the use of COBOL cripples the mind".<ref name="Dijkstra1">{{cite web |url=http://www.cs.utexas.edu/users/EWD/transcriptions/EWD04xx/EWD498.html |title=How do we tell truths that might hurt? |access-date=29 August 2007 |publisher=University of Texas at Austin |date=18 June 1975 |last=Dijkstra |first=Edsger W. |id=EWD498 |archive-url= https://web.archive.org/web/20170502143353/http://www.cs.utexas.edu/users/EWD/transcriptions/EWD04xx/EWD498.html |archive-date=2 May 2017 |url-status=dead}}</ref>

In a published dissent to Dijkstra's remarks, the computer scientist Howard E. Tompkins claimed that [[unstructured programming|unstructured]] COBOL tended to be "written by programmers that have never had the benefit of structured COBOL taught well", arguing that the issue was primarily one of training.<ref>{{Cite journal |doi= 10.1145/948176.948186| title=In defense of teaching structured COBOL as computer science| journal=ACM SIGPLAN Notices| volume=18| issue=4| pages=86–94| year=1983| last1=Tompkins| first1=H. E.| s2cid=33803213| doi-access=free}}</ref>

One cause of [[spaghetti code]] was the {{code|GO TO}} statement. Attempts to remove {{code|GO TO}}s from COBOL code, however, resulted in convoluted programs and reduced code quality.{{sfn|Riehle|1992|p=125}} {{code|GO TO}}s were largely replaced by the {{code|PERFORM}} statement and procedures, which promoted [[modular programming]]{{sfn|Riehle|1992|p=125}} and gave easy access to powerful looping facilities. However, {{code|PERFORM}} could be used only with procedures so loop bodies were not located where they were used, making programs harder to understand.{{sfn|Shneiderman|1985|pp=349–350}}

COBOL programs were infamous for being monolithic and lacking modularization.<ref>{{cite book | url=https://books.google.com/books?id=MJmJAwAAQBAJ&pg=PA4 | title=Beginning COBOL for Programmers | publisher=Apress | access-date=13 August 2014 | page=4 | first=Michael | last=Coughlan | isbn=978-1430262534 | date=16 March 2014}}</ref>
COBOL code could be modularized only through procedures, which were found to be inadequate for large systems. It was impossible to restrict access to data, meaning a procedure could access and modify {{em|any}} data item. Furthermore, there was no way to pass [[parameter (computer programming)|parameter]]s to a procedure, an omission Jean Sammet regarded as the committee's biggest mistake.{{sfn|Sammet|1978b|p=258}}

Another complication stemmed from the ability to {{code|PERFORM THRU}} a specified sequence of procedures. This meant that control could jump to and return from any procedure, creating convoluted control flow and permitting a programmer to break the [[single-entry single-exit]] rule.{{sfn|Riehle|1992|p=126}}

This situation improved as COBOL adopted more features. COBOL-74 added subprograms, giving programmers the ability to control the data each part of the program could access. COBOL-85 then added nested subprograms, allowing programmers to hide subprograms.{{sfn|Riehle|1992|p=127}} Further control over data and code came in 2002 when object-oriented programming, user-defined functions and user-defined data types were included.

Nevertheless, much important legacy COBOL software uses unstructured code, which has become practically unmaintainable. It can be too risky and costly to modify even a simple section of code, since it may be used from unknown places in unknown ways.<ref>{{Cite web|url=http://www.nakedcapitalism.com/2016/07/cobol-and-legacy-code-as-a-systemic-risk.html?imm_mid=0e6043&cmp=em-prog-na-na-newsltr_20160723|title=COBOL and Legacy Code as a Systemic Risk {{!}} naked capitalism|date=19 July 2016|language=en-US|access-date=23 July 2016}}</ref>

===Compatibility issues===
COBOL was intended to be a highly portable, "common" language. However, by 2001, around 300 dialects had been created.<ref>{{cite journal | url=http://www.cs.vu.nl/grammarware/500/500.pdf | title=Cracking the 500-language problem | journal=IEEE Software |date=November–December 2001 | volume=18 | issue=6 | page=79 | doi=10.1109/52.965809 | first1=Ralf | last1=Lämmel | first2=Chris | last2=Verhoef | hdl=1871/9853 | author-link2 = Chris Verhoef| archive-url=https://web.archive.org/web/20140819085841/http://www.cs.vu.nl/grammarware/500/500.pdf | archive-date=19 August 2014 | url-status=dead}}</ref> One source of dialects was the standard itself: the 1974 standard was composed of one mandatory nucleus and eleven functional modules, each containing two or three levels of support. This permitted 104,976 possible variants.<ref>{{cite journal | title=Towards more portable COBOL | journal=The Computer Journal | date=April 1979 | volume=22 | issue=4 | pages=290 | doi=10.1093/comjnl/22.4.290 | first1=T. J. | last1=Howkins | first2=M. T. | last2=Harandi | doi-access=free }}</ref>

COBOL-85 was not fully compatible with earlier versions, and its development was controversial. Joseph T. Brophy, the [[Chief Information Officer|CIO]] of [[St. Paul Travelers|Travelers Insurance]], spearheaded an effort to inform COBOL users of the heavy reprogramming costs of implementing the new standard.{{sfn|Garfunkel|1987|p=11}} As a result, the ANSI COBOL Committee received more than 2,200 letters from the public, mostly negative, requiring the committee to make changes. On the other hand, conversion to COBOL-85 was thought to increase productivity in future years, thus justifying the conversion costs.{{sfn|Garfunkel|1987|p=15}}

===Verbose syntax===
{{quote box
 | title=COBOL: /koh′bol/, n.
 | tstyle=text-align: left;
 | quote=A weak, verbose, and flabby language used by code grinders to do boring mindless things on dinosaur mainframes. [...]  Its very name is seldom uttered without ritual expressions of disgust or horror.
 | source=[[The Jargon File]] 4.4.8.<ref>{{cite web | url=http://catb.org/jargon/html/C/COBOL.html | title=COBOL | work=The Jargon File, version 4.4.8 | date=1 October 2004 | access-date=13 December 2014 | first=Eric S. | last=Raymond | author-link=Eric S. Raymond | url-status=live | archive-url=https://web.archive.org/web/20140830184553/http://www.catb.org/jargon/html/C/COBOL.html | archive-date=30 August 2014}}</ref>
 | align=right
 | width=30%
 | quoted=1
}}

COBOL syntax has often been criticized for its verbosity. Proponents say that this was intended to make the code [[self-documenting]], easing program maintenance.{{sfn|Brown|1976|p=53}} COBOL was also intended to be easy for programmers to learn and use,{{sfn|CODASYL|1969|loc=§ II.1.1}} while still being readable to non-technical staff such as managers.{{sfn|Shneiderman|1985|p=350}}{{sfn|Sammet|1961|p=381}}{{sfn|Conner|1984|p=ID/10}}{{sfn|Marcotty|1978a|p=263}}

The desire for readability led to the use of English-like syntax and structural elements, such as nouns, verbs, clauses, sentences, sections, and divisions. Yet by 1984, maintainers of COBOL programs were struggling to deal with "incomprehensible" code{{sfn|Conner|1984|p=ID/10}} and the main changes in COBOL-85 were there to help ease maintenance.<ref name="Computerworld Garfunkel" />

Jean Sammet, a short-range committee member, noted that "little attempt was made to cater to the professional programmer, in fact people whose main interest is programming tend to be very unhappy with COBOL" which she attributed to COBOL's verbose syntax.{{sfn|Conner|1984|p=ID/14}}

{{quote box
 | title=
 | tstyle=text-align: left;
 | quote=The academic world tends to regard COBOL as verbose, clumsy and inelegant, and tries to ignore it, although there are probably more COBOL programs and programmers in the world than there are for FORTRAN, ALGOL and PL/I combined. For the most part, only schools with an immediate vocational objective provide instruction in COBOL.
 | source=[[Richard W. Conway|Richard Conway]] and [[David Gries]], 1973<ref name="conway-gries">{{cite book |last1=Conway |first1=Richard  |last2=Gries |first2=David |year=1973 |title=An Introduction to Programming: A Structured Approach using PL/1 and PL/C |publisher=Winthrop Publishers |location=Cambridge, Massachusetts | page=341 | isbn=0-87626-405-4 }}</ref>
 | align=left
 | width=30%
 | quoted=1
}}

Later, COBOL suffered from a shortage of material covering it; it took until 1963 for introductory books to appear (with Richard D. Irwin publishing a college textbook on COBOL in 1966).<ref>{{Cite web |url=https://books.bibliopolis.com/main/find/2200821/COBOL-Logic-and-Programming-third-edition-1974-McCameron-Fritz-oldcomputerbooks-com.html |title=COBOL Logic and Programming, third edition 1974 |access-date=25 February 2016 |archive-url=https://web.archive.org/web/20160305083547/https://books.bibliopolis.com/main/find/2200821/COBOL-Logic-and-Programming-third-edition-1974-McCameron-Fritz-oldcomputerbooks-com.html |archive-date=5 March 2016 |url-status=dead }}</ref> Donald Nelson, chair of the CODASYL COBOL committee, said in 1984 that "academics ... hate COBOL" and that computer science graduates "had 'hate COBOL' drilled into them".<ref>{{cite journal| url=https://books.google.com/books?id=VQhbdDusHcsC&pg=RA1-PA61 | title=An interview: Cobol defender | journal=Computerworld | date=10 September 1984 | access-date=8 June 2014 | author=<!-- Staff writer(s); No by-line --> | pages=ID/29–ID/32 | volume=18 | issue=37}}</ref>

By the mid-1980s, there was also significant condescension towards COBOL in the business community from users of other languages, for example [[FORTRAN]] or [[assembler language|assembler]], implying that COBOL could be used only for non-challenging problems.<ref>{{cite book |last1=Pratt |first1=Terrence W. |last2=Zelkowitz |author2-link=Marvin Victor Zelkowitz|first2=Marvin V. |date=1984 |edition=2nd |title=Programming Languages: Design and Implementation |publisher=Englewood Cliffs, N.J. : Prentice Hall |isbn=0136780121}}</ref>

In 2003, COBOL featured in 80% of [[information systems]] curricula in the United States, the same proportion as [[C++]] and [[Java (Programming language)|Java]].{{sfn|Carr|Kizior|2003|p=13}} Ten years later, a poll by [[Micro Focus]] found that 20% of university academics thought COBOL was outdated or dead and that 55% believed their students thought COBOL was outdated or dead. The same poll also found that only 25% of academics had COBOL programming on their curriculum even though 60% thought they should teach it.<ref>{{cite press release | url=http://www.microfocus.com/about/press/pressreleases/2013/pr070320131001.aspx | title=Academia needs more support to tackle the IT skills gap | publisher=Micro Focus | date=7 March 2013 | access-date=4 August 2014}}</ref>

===Concerns about the design process===
Doubts have been raised about the competence of the standards committee. Short-term committee member Howard Bromberg said that there was "little control" over the development process and that it was "plagued by discontinuity of personnel and ... a lack of talent."{{sfn|Beyer|2009|p=301}} Jean Sammet and Jerome Garfunkel also noted that changes introduced in one revision of the standard would be reverted in the next, due as much to changes in who was in the standard committee as to objective evidence.<ref>{{cite journal | title=Summary of Changes in COBOL, 1960–1985 | journal=Annals of the History of Computing | date=October 1985 | volume=7 | issue=4 | pages=342 | first1=Jean | last1=Sammet | first2=Jerome | last2=Garfunkel | doi=10.1109/MAHC.1985.10033 | s2cid=17940092 }}</ref>

COBOL standards have repeatedly suffered from delays: COBOL-85 arrived five years later than hoped,<ref>{{cite conference | url=http://www.computer.org/csdl/proceedings/afips/1978/5086/00/50861107.pdf | title=Data Base Facility for COBOL 80 | first=Margaret M. | last=Cook | conference=1978 National Computer Conference | quote=The earliest date that a new COBOL standard could be developed and approved is the year 1980 [...]. | pages=1107–1112 | publisher=AFIPS Press | date=June 1978 | location=Anaheim, California | lccn= 55-44701 | doi=10.1109/AFIPS.1978.63 | access-date=2 September 2014 | editor1-last=Ghosh | editor1-first=Sakti P. | editor2-last=Liu | editor2-first=Leonard Y.}}</ref> COBOL 2002 was five years late,<ref name="SW95"/> and COBOL 2014 was six years late.<ref name="cobolstandards.com"/><ref>{{cite web | url=http://www.cobolstandard.info/wg4/open/wg4n0188.doc | title=Resolutions from WG4 meeting 24 – June 26–28, 2003 Las Vegas, Nevada, USA | date=11 July 2003 | access-date=29 June 2014 | format=doc | quote=a June 2008 revision of the COBOL standard | page=1 | url-status=dead | archive-url=https://web.archive.org/web/20160308015945/http://www.cobolstandard.info/wg4/open/wg4n0188.doc | archive-date=8 March 2016}}</ref> To combat delays, the standard committee allowed the creation of optional addenda which would add features more quickly than by waiting for the next standard revision. However, some committee members raised concerns about incompatibilities between implementations and frequent modifications of the standard.<ref>{{cite journal | url=https://books.google.com/books?id=tQOdtdJmVSsC&pg=PA12 | title=Cobol standard add-ons flayed | journal=Computerworld | volume=20 | issue=28 | pages=1, 12 | first=Charles | last=Babcock | date=14 July 1986}}</ref>

===Influences on other languages===
COBOL's data structures influenced subsequent programming languages. Its record and file structure influenced [[PL/I]] and [[Pascal (programming language)|Pascal]], and the <code>REDEFINES</code> clause was a predecessor to Pascal's variant records. Explicit file structure definitions preceded the development of [[database management systems]] and aggregated data was a significant advance over Fortran's arrays.{{sfn|Shneiderman|1985|p=349}}

<code>PICTURE</code> data declarations were incorporated into PL/I, with minor changes.

COBOL's {{code|COPY}} facility, although considered "primitive",{{sfn|Marcotty|1978b|p=274}} influenced the development of [[include directive]]s.{{sfn|Shneiderman|1985|p=349}}

The focus on portability and standardization meant programs written in COBOL could be portable and facilitated the spread of the language to a wide variety of hardware platforms and operating systems.<ref>This can be seen in:

* {{cite web|ref=none | url=http://www-304.ibm.com/partnerworld/gsd/solutiondetails.do?solution=48040&expand=true&lc=en | title=Visual COBOL | publisher=[[IBM]] | work=IBM PartnerWorld | date=21 August 2013 | access-date=5 February 2014 | quote=Micro Focus Visual COBOL delivers the next generation of COBOL development and deployment for Linux x86-64, Linux for System z, AIX, HP/UX, Solaris, and Windows. | archive-url=https://web.archive.org/web/20140712183624/http://www-304.ibm.com/partnerworld/gsd/solutiondetails.do?solution=48040 | archive-date=12 July 2014 | url-status=live}}
* {{cite web|ref=none | url=https://www.ibm.com/products/cobol-compiler-family | title=IBM COBOL Compiler Family | date=16 May 2024 | publisher=[[IBM]] | access-date=11 September 2024}}
* {{cite web|ref=none | url=https://gnucobol.sourceforge.io | title=GnuCOBOL - GNU Project | access-date=11 September 2024}}
</ref> Additionally, the well-defined division structure restricts the definition of external references to the Environment Division, which simplifies platform changes in particular.<ref name="cobol-intro">{{cite web | url=http://www.csis.ul.ie/cobol/course/COBOLIntro.htm#part1 | title=Introduction to COBOL | year=2002 | archive-date=5 March 2023 | archive-url=https://web.archive.org/web/20230305155004/https://www.csis.ul.ie/cobol/course/COBOLIntro.htm | last=Coughlan |first=Michael}}</ref>