| COBOL is a third-generation programming
language. Its name is an acronym, for COmmon Business
Oriented Language, defining its primary domain in business, finance, and administrative systems for companies
and governments.
The COBOL 2002 standard includes support for object-oriented programming and other modern language features. However, most of
this article is based on COBOL 85.
Prehistory and specification
COBOL was initially created in 1959 by The Short Range Committee,
one of three committees proposed at a meeting held at the Pentagon in
May 1959, organized by Charles Phillips of the United States Department of Defense. The Short Range Committee was formed to recommend
a short range approach to a common business language. It was made up of members representing six computer manufacturers and three
government agencies. In particular, the six computer manufacturers were Burroughs Corporation, IBM, Minneapolis-Honeywell (Honeywell
Labs), RCA, Sperry Rand, and Sylvania Electric Products. The three government
agencies were the US Air Force, the David Taylor Model Basin, and the National Bureau of Standards (Now NIST). This
committee was chaired by a member of the NBS. An Intermediate-Range Committee and a Long-Range Committee were proposed at the
Pentagon meeting as well. However although the Intermediate Range Committee was formed, it was never operational; and the
Long-Range Committee was never even formed. In the end a sub-committee of the Short Range Committee developed the specifications
of the COBOL language. This sub-committee was made up of six individuals:
This subcommittee completed the specifications for COBOL as the year of 1959 came to an end. The specifications were to a
great extent inspired by the FLOW-MATIC language invented by Grace Hopper, and the IBM COMTRAN language invented by Bob Bemer.
The specifications were approved by the full Short Range Committee. From there, they were approved by the Executive Committee
in January 1960, and sent to the government
printing office, which edited and printed these specifications as Cobol 60. COBOL was developed within a six month period, and yet is still in use over 40 years
later.
Defining features
COBOL as defined in the original specification, possessed excellent self-documenting capabilities, good file handling methods,
and exceptionally good data typing for the time, owing to its use of the PICTURE clause for detailed field specification. However
by modern standards for programming language definition, it had serious flaws, notably verbose syntax and lack of support for
local variables, recursion, dynamic memory allocation, and structured programming. Its lack of support for object-oriented programming is understandable, given that the concept was unknown at the time
COBOL has many reserved words, and it is hard to avoid unintentionally
using one, without using some convention such as adding an unlikely prefix to all variable names. The original COBOL
specification even supported self-modifying code via the
famous "ALTER X TO PROCEED TO Y" statement. Consequently, little new code is being written in COBOL. However, the COBOL
specification has been redefined over the years to address some of these criticisms. and later definitions of COBOL have remedied
many of these lacks, adding improved control structures, object-orientation and removing the ability to use self-modifying
code.
Still going strong
Many COBOL programs are still in use in major commercial enterprises, notably financial institutions. The expense of rewriting a very large code base, that has already been
debugged, in a new language has not been thought worth any benefits that might ensue. Near the end of the twentieth century there
was a flurry of activity for COBOL programmers fixing the year 2000
problem, sometimes in systems the same programmers had designed decades before. This problem was especially prevalent in
COBOL code because dates are relevant in business applications, and most old business applications were written in COBOL.
Some people think that the use of binary-coded decimal
arithmetic in its design happened to make programs designed without provision for the advent of the 2000s particularly vulnerable
to failure with the year 2000 problem; however, it is difficult
to see why they should have formed this opinion. Others argue that COBOL's BCD arithmetic avoided many other problems that can
occur with the naïve use of floating point for financial
calculations.
COBOL has proven to be durable and adaptable. For example, IBM zSeries COBOL now
supports modern conveniences such as Unicode, XML
generation and parsing, and calling conventions to/from Java (including COBOL instantiated as EJBs).
Hello world
IDENTIFICATION DIVISION.
PROGRAM-ID. HELLO-WORLD.
*
ENVIRONMENT DIVISION.
*
DATA DIVISION.
*
PROCEDURE DIVISION.
PARA-1.
DISPLAY "Hello, world.".
*
EXIT PROGRAM.
END PROGRAM HELLO-WORLD.
If you copy and paste this example then be careful to preserve the indentation, as indentation is relevant to (at least) older
COBOL compilers. If you're trying to compile this example on a older compiler and it fails to compile or produces no output when
run, you may want to try a more simple example
(http://www.cuillin.demon.co.uk/nazz/trivia/hw/hw_cobol.html).
Opposing views on COBOL
Criticism
A motivation of COBOL's design was to make programming easier by making the language as English-like as possible. While this
idea seems reasonable on its face, in practice the most difficult task in programming is reducing a complex computation to a
sequence of simple steps, a task that only few real new-age programmers know how, or even want to do. Nevertheless, critics
therefore argue that COBOL's verbose syntax serves mainly to increase the size of programs, and that it impairs the development
of the precise thinking needed for software development. Computer scientist Edsger Dijkstra remarked in his 1975 article "How do we tell truths that might hurt?", "The use of COBOL
cripples the mind; its teaching should, therefore, be regarded as a criminal offence." But Dijkstra was also positively impressed
by Michael A. Jackson's ideas about "Structured Programming" in
COBOL (Jackson Structured
Programming).
The SQL language, which follows COBOL's philosophy but is not used to write procedural
code, has not faced as much criticism about its syntax.
Some programmers joke that the object-oriented extension of COBOL should be called ADD 1 TO COBOL GIVING COBOL. This is by
analogy with C++, a pun on C's syntax for incrementing a variable in place, and it highlights the verbosity of COBOL's syntax
compared to C. Actually, the basic form is "ADD 1 TO COBOL", incrementing the variable in place, as C.
Defense
On the other hand, COBOL advocates claim that typically those who criticize COBOL and make fun of the language have never been
COBOL programmers and often misrepresent the language. In almost all modern COBOL implementations, the compilers are not case
sensitive, although the compiler will capitalize all keywords prior to parsing.
If one wants to make COBOL more verbose than it has to be, one usually can. For example, this COBOL code:
ADD A TO B GIVING C.
DIVIDE 2 INTO C GIVING C.
can be written like this:
COMPUTE C = (A + B) / 2.
and the "compute" verb can handle quite complex and deeply-nested statements in algebraic form.
Terse programming languages like C may encourage developers to write code that is hard to understand or debug, but COBOL
encourages writing code that is understandable at least at the statement level.
References
- Sammet, J.E. (1981). "The Early History of COBOL." In History of Programming Languages, by Wexelblat, R.L., ed. New
York: ACM Monograph
Series.
External links
|
