Software Engineering for Students A Programming Approach

14.3 Design principles 177
Cobol and PL/1 are examples of languages which are large and unwieldy. For
example, Cobol currently contains about 300 reserved words. Not surprisingly, it is a
common programming error mistakenly to choose a reserved word as a user-defined
identifier. What are the problems of large languages? Because they contain so many
features, some are seldom used and, consequently, rarely fully understood. Also, since
language features must not only be understood independently, but also in terms of their
interaction with each other, the larger the number of features, the more complex it will
be and the harder to understand their interactions. Although smaller, simpler languages
are clearly desirable, the software engineer of the near future will often have to wrestle
with existing large, complex languages. For example, to meet the requirements laid
down by its sponsors, the US Department of Defense, the programming language Ada
is a large and complex language requiring a 300-page reference manual to describe it.
The clarity of a language is also an important factor. In recent years, there has been
a marked and welcome trend to design languages for the programmers who program
in them rather than for the machines the programs are to run on. Many older languages
incorporate features that reflect the instruction sets of the computers they were originally
designed to be executed on. As one example, consider the Fortran arithmetic if
statement, which has the following form:
if (expression) label1,label2,label3
This statement evaluates expression and then branches to one of the statements
labeled label1, label2, or label3 depending on whether the result is positive, zero,
or negative. The reason for the existence of this peculiar statement is that early IBM
machines had a machine instruction which compared the value of a register to a value
in memory and branched to one of three locations. The language designers of the
1960s were motivated to prove that high-level languages could generate efficient code.
Although we will be forever grateful to them for succeeding in proving this point, they
introduced features into languages, such as Cobol and Fortran, which are clumsy and
error-prone from the programmer’s viewpoint. Moreover, even though the languages
have subsequently been enhanced with features reflecting modern programming ideas,
the original features still remain.
A programming language is the tool that programmers use to communicate their
intentions. It should therefore be a language which accords with what people find natural,
unambiguous and meaningful – in other words, clear. Perhaps language designers
are not the best judges of the clarity of a new language feature. A better approach to
testing a language feature may be to set up controlled experiments in which subjects are
asked to answer questions about fragments of program code. This experimental psychology
approach is gaining some acceptance and some results are discussed in the section
on control abstractions.
A programmer can only write reliable programs if he or she understands precisely
what every language construct does. The quality of the language definition and supporting
documentation are critical. Ambiguity or vagueness in the language definition
erodes a programmer’s confidence in the language. It should not be necessary to have
to write and run a program fragment to confirm the semantics of some language feature.