Information Technology Reference
In-Depth Information
were provided. In many cases, compromises were made that allowed for
confl icting interpretations of what made for “readable” computer code.
Arithmetic formulas, for instance, could either be written using a com-
bination of arithmetic verbs—that is, ADD, SUBTRACT, MULTIPLY,
or DIVIDE—or as symbolic formulas. The use of arithmetic verbs was
adapted directly from the FLOW-MATIC language, and refl ected the
belief that business data processing users could not—and should not—be
forced to use formulas. The capability to write symbolic formulas was
included (after much contentious debate) as a means of providing power
and fl exibility to more mathematically sophisticated programmers. Such
traditional mathematical functions such as SINE and COSINE, however,
were deliberately excluded as being unnecessary to business data process-
ing applications.
Another concession to the objective of readability was the inclusion
of extraneous “noise words.” These were words or phrases that were
allowable but not necessary: for example, in the statement
READ
fi le1
RECORD INTO
variable1
AT END
goto procedure2
the words RECORD and AT are syntactically superfl uous. The statement
would be equally valid written as
READ
fi le1
INTO
variable1
END
goto procedure2
.
The inclusion of the noise words RECORD and AT was perceived by
the designers to enhance readability. Users had the option of including
or excluding them according to individual preference or corporate
policy.
In addition to designing COBOL to be Englishlike and readable,
the committee was careful to make it as machine-independent as
possible. Most contemporary programming systems were tied to a spe-
cifi c processor or product line. If the user wanted to replace or upgrade
their computer, or switch to machines from a different manufacturer,
they had to completely rewrite their software from scratch, typically an
expensive, risky, and time-consuming operation. Users often became
bound to outdated and ineffi cient hardware systems simply because
of the enormous costs associated with upgrading their software
applications. This was especially true for commercial data processing
operations, where computers were generally embedded in large, complex
systems of people, procedures, and technology. A truly machine-
independent language would allow corporations to reuse application
code, thereby reducing the programming and maintenance costs. It would
