The Best of Creative Computing Volume 1 (published 1976)
Toward a Human Computer Language
us on to better designs? And, since every programmer was
once a novice, shouldn't we be concerned with the nature
of a programming language's structure and the ease with
which its full powers can be grasped and applied to
problems that its users wish to solve? I'll use some notable
failures in language design to illustrate things with which we
should not be satisfied and to show why the answer to the
latter question should be an emphatic "yes".
Almost everyone is familiar with one of the more
primitive programming languages like Fortran and Basic
(proper nouns both, and deserving of no more capitals than
God and Man). Why is "primitive" a justifiable modifier?
For example, consider Fortran (historically an acronym for
"formula translator"). Created as a way of making algebraic
expressions more easily entered (by humans) into a
machine, thus more readable than lists of individual
machine instructions, it served to express formulas in
notation consistent with common mathematics - the same
notation for all machines having a Fortran -tanslator
program (compiler). Two decades ago, this was a step in
closing the gap between computer and human vernaculars.
But even then it was clear that a useful machine, which can
parse "(2appI es 3lemons)/1.8fruitperpound", must also
handle control commands, like "do this then do that until
something happens", with clarity and ease. Hackneyed
design gave Fortran, among other defects, less power to
express the control of a program's execution than to parse
an algebraic expression, and so eternally placed arcane and
unnecessary burdens upon its users. Similar remarks apply
to Basic, originally designed as a simple, stopgap recoding
of machine language for users of early time-sharing systems.
Some examples:
English/Algebra
If (2 apples 3 lemons) / 1.8 fruit per pound is > 0 then do
this, if it is = 0 then do that, otherwise do the other thing.
Fortran
FRUTLB = 1.8
lF ((2*apples 3*lemons)/FRUTLB)100,200,300
100 ...
200 ...
300 ...
Basic
10 LET X = (2*A 3*L)/1.8
20 lF X<0 THEN 100
30 lF X=0 THEN 200
40 lF X>0 THEN 300
100 ...
200 ...
300 ...
Algol
real x, fruitperpound; fruitperpound := 1.8; if (x :=
(2*apples 3*lemons)/fruitperpound) > 0 then this else if
x = 0 then that else theotherthing;
The Fortran and Basic examples highlight the glaring
inconsistency of easy algebra and sorry obfuscation of
control. Suppose we had to write the algebra as:
10 2
20 APPLES
30 *
40 3
50 LEMONS
60
70 1.8
80 /
Would or should we be happy with such a Iobotomized
language? Perhaps for a $20 calculator. And never mind
trying to recall what goes on at lines 100, 200 and 300,
which may be pages away (or cards away on archaic
systems) in the program's text. Yet many people,deprived
of access to anything else, believe that Fortran, Basic, etc.
are the essence of programming! Perhaps our true shame is
that we inflict our most scurrilous languages upon our
school-children, in whose lives the vast potential of the
computer will have greatest meaning. We've mused that
there is no complete and satisfactory language, not yet-
certainly if too many of us continue to accept naively the
ravings of foppish languages there may never be.
It's obvious which of the examples above (Algol, over a
decade old) most closely approaches English and some of
this is just nice form. We naturally like to call things
(variables, labels, procedures) by names that indicate to us
their significance. Notice that Fortran and Basic limit even
this simple ability by restricting name lengths and character
content (it is irrelevant that different versions of these
languages impose different limits). Utter trivia like
non-free-field syntax (e.g. Fortran statements must begin
after column 6 (or is it 5?)) further subordinate the
programmer's daily convenience to the one-time conven-
ience of the language designer. Sometimes, on some
machines, some such restrictions result from necessary
trade-offs. But even on the smallest machine,a compiler or
interpreter that reasonably sacrifices niceties of form
should never be allowed to sacrifice the essentials of
consistency and intelligibility.
Notice that Fortran misappropriates "=" as the
assignment operator and leaves the user with either: "IF
(X - 2) 100, 200, 100" or "IF (X .EQ.2)GO TO 200" as
means for testing equality (in this case of X and 2). Basic at
least retains the usual meaning of "=", but at the price of
adding an extra, prefix operator "LET". As a result of these
kinds of patchy designs, such languages are poorly defined
and give the user no consistent means for mastering their
syntax. Special cases abound. Locally, the syntax may be
postfix, prefix or infix and the same element (e.g. "IF" in
Fortran, "=" in Basic) may have different meanings,
depending upon its context. Human languages do the same
sort of thing, but not at such low levels.
Fortran "format" statements provide perhaps the most
horrendous example of a language patched within a
language. Mastery of their syntax alone has provided jobs
and income for many programmers.Interestingly, the
tendency is to modify Fortran and Basic by adding
"features". Since the languages have no particular structure
anyway, these are cut-and-paste enterprises. One notable
result has been Pl/1, which fearlessly combines the syntaxes
of Algol, Cobol and Fortran into something like the worst
of all possible worlds! lt solves few of the inconsistencies
and frivolities of either Fortran or Cobol (e.g. noise words
which seem to mean what they mean in English but mean
nothing!) and abuses a well-defined language: Algol-60.
Unfortunately,Pl/1 seems to be the product of
bigger-is-better reasoning. When a language is designed in
such a way as to make it harder to read or to explain, then
we should be suspicious that it lacks usefulness as well as
elegance. It is of course true that not everyone who uses a
computer has clear, elegant languages at his or her disposal,
but we should all be aware of needs and opportunities for
changing such situations. Here are two examples of a
guessing game written by children in Basic and Logo (which
borrows ideas from Algol and Lisp):
