In Praise of APL:
A Language for Lyrical Programming
Professor Alan J. Perlis
Yale University

 

Many reasons can be given for teaching
one or more aspects of computer
science (defined as the study of the set
of phenomena arising around and because of
the computer) to all university students.
Probably every reader of this note supports
some of these reasons. Let me list
the few I find most important: (1) to
understand and to be able to compose
algorithms; (2) to understand how computers
are organized and constructed; (3) to
develop fluency in (at least) one programming
language; (4) to appreciate the
inevitability of controlling complexity
through the design of systems; (5) to
appreciate the devotion of computer
scientists to their subject and the
exterior consequences (to the student as
citizen) of the science’s development.

Even though computer science deals
with symbolic objects whose nature we
study mathematically, it cannot be taught
as an orderly development arising from a
few fundamental ideas whose existence the
student has already observed intuitively
during his maturation, such as gravitation
and electricity.

It is during this first computer
course that the student awakes to the
possibilities and consequences of computation.
They arise most usefully and in
greatest profusion during his writing of
programs. He must program and program and
program! He must learn how to state
precisely in a programming language what
he perceives about the nature of symbolic
systems. I know of no better way to
expedite this awakening than by programming.

But what should the student program?
and in what language? I do not place much
emphasis on heavy use of other people’s
programs, packages if you will, that
perform real services such as statistical
packages, data management systems, linear
equations solvers, etc. While it is wise
to use standard programs when they match
one’s needs, it is more important to
master self-expression during this initial
contact.

Available time is a limiting factor;
a semester provides about 16 weeks of
contact. During that interval the student
must negotiate a set of tasks that sharpens
his abilities and explodes his perceptions
of the computer’s capabilities. He
must be on the computer early and often
during the semester and his approach to it
must be smooth and easy. The computer
system he uses should be time-sharing and
interactive, if you will.

Learning to program involves a
sequence of acts of discovery punctuated
by recovery from errors. As the semester
progresses the causes and nature of errors
will change. Certain kinds will diminish
and even disappear, only to be replaced by
errors of deeper significance, harder to
isolate and more resistant to satisfactory
removal — syntactic gaffes give way to
semantic errors — incorrect perceptions
of purpose, improper use of means, the use
of hammers to swat flies and swatters to
level mountains.

To write correct and balanced programs
a student may be forced to move
between programs that are not related to
each other by a few simple textual rearrangements.
He must learn to write and
test complicated programs quite rapidly.
As he moves through the sequence of
assigned tasks his ability to express
himself fluently should not founder too
soon because of language shortcomings.
For all of the above reasons as well as a
few others, I have come to believe that
APL is the most rational first language
for a first course in computer science.

It is true that BASIC and FORTRAN are
easier to learn than APL, for example, a
week versus a month. However, once
mastered, APL fits the above requirements
much better than either BASIC or FORTRAN
or their successors ALGOL 60, PL/I and
Pascal. The syntax of APL is not a
significant difficulty for the students.
The large number of primitive functions,
at first mind-numbing in their capabilities,
quickly turn out to be easily
mastered, soon almost all are used naturally
in every program — the primitive
functions form a harmonious and useful
set. As a data organization, arrays turn
out to be extraordinarily useful (though
prolonged contact with APL makes one wish
for the added presence of more heterogeneous
structures).

Style and Idiom

The virtues of APL that strike the
programmer most sharply are its terseness
— complicated acts can be described
briefly, its flexibility — there are a
large number of ways to state even moderately
complicated tasks (the language
provides choices that match divergent
views of algorithm construction), and its
composability — there is the possibility
to construct sentences — one-liners as
they are commonly called — that approach
in the flow of phrase organization,
sequencing and imbedding, the artistic
possibilities achievable in natural
language prose.

The sweep of the eye across a single
sentence can expose an intricate, ingenious
and beautiful interplay of operation
and control that in other programming
languages is observable only in several
pages of text. One begins to appreciate
the emergence and significance of style
and to observe that reading and writing
facility is tied to the development of an
arsenal of idioms which soon become
engraved in one’s skull as units.

The combination of these three
factors makes it possible to develop an
excellent set of exercises in the first
course. These exercises can be large in
number, cover a wide range of topics and
vary widely in complexity, and still be
done during the 16 week period. The later
exercises can be tied to the design and
development of a system — a collection of
procedures that, in varying combinations,
perform a set of tasks.

In Teaching Computer Organization

To appreciate computer science one
requires an understanding of the computer.
Once the student understands the computer
— its macroscopic components monitored by
the fetch-execute cycle and its apparent
complexity being controlled by gigantic
replication of a few simple logical
elements — he can become aware of the
important equilibrium between hardware and
software — the shifting of function
between the two as determined by economic
factors — and between algorithm and
system as determined by traffic and
variation. Using APL it is straightforward
to model a computer and to illustrate
any of its macroscopic or microscopic
components at any level of detail. The
programs to perform these functions at
every level of description remain small
and manageable — about 40 lines or so.

The development of software, e.g., a
machine language assembler, is a task of
similar difficulty (about 40 lines) and
hence possible within the confines of a
first course.

Word processing and graphics,
increasingly important application areas
of computers, can be explored with exercises
of no great size, e.g., to do
permuted-index of title lists (~12 lines),
display, rotation and scaling of composites
of polygons (~20 lines), graphing of
functions (~5 lines), etc.

With (or even without) the use of 2
or 3 pre-built functions, file processing
problems such as payroll, personnel
search, etc. can be written in a relatively
few lines.

An important consequence of the
attainable brevity of these compositions
cannot be ignored: the student becomes
aware that he need not be forced to depend
upon external, pre-packaged and elaborate
systems to do what are really simple
programming tasks. Instead of learning a
new coding etiquette to negotiate a
complex external system, he writes his own
programs, develops his own systems tailor-made
to his own needs and understood at
all levels of detail by him. If anything
is meant by man-machine symbiosis, it is
the existence of such abilities on the man
side of the “membrane”, for there is no
partnership here between man and machine,
merely the existence of a growing, but
never perfectly organized, inventory of
tools that the competent can pick among,
adapt and use to multiply his effective
use of the computer.

I cannot overemphasize the importance
of terseness, flexibility and phrase
growth to a beginning student. His
horizons of performance are being set in
this first course. If he sees a task as a
mountain then its reduction to molehill
proportions is itself a considerable
algorithmic task. While this is true of
very large tasks, even when using APL this
conscious chaining of organized reductions
can be postponed until the student has
already collected a large number of useful
data-processing functions, engraved in his
skull, with which to level mountains.

It is important to recognize that no
matter how complicated the task, the APL
functions will usually be anywhere from
1/5 to 1/10 the number of statements or
lines, or what have you, of a FBAPP
(FORTRAN or BASIC or ALGOL or PL/I or
Pascal) program. Since APL distributes,
through its primitive functions, control
that the other languages explicate via
sequences of statements dominated by
explicit control statements, errors in APL
programs tend to be far fewer in number
than in their correspondents in FBAPP.

I can come now to the topics of
structured programming and program verification.
Both are important, but their
content and importance depend strongly on
the language in which programs are
couched. A program is well-structured if
it has a high degree of lexical continuity:
small changes in program capability
are acquired by making changes within
lexically close text (modularization).

Since APL has a greater density of
function within a given lexical scope than
FBAPP, one would expect that APL programs
will support considerably more structure
than equivalent size FBAPP programs. Put
another way, since the APL programs are
1/5 to 1/10 the size of FBAPP programs,
the consequences to APL programs of weak
structuring are less disastrous. Recovery
from design mistakes is more rapid. Since
we can only structure what we already
understand, the delay in arriving at
stable program organization should be
considerably less with FBAPP!

Please note that the emphasis here is
on the control of propagation of relationships,
not the nonsense of restricting goto
or bathing programs in cascades of
while loops.

The verification, formal or informal,
of programs is a natural and important
activity. It is linked to specification:
what we can’t specify we can’t verify. By
specification we mean stating what is to
be output for a given input. We immediately
observe that, since specification in
FBAPP is extremely tedious and unnatural,
we must use some other language. APL
turns out to be quite good and has often
been suggested as a specification language.
Assertions and verification
conditions can be much more easily
expressed as APL predicates than as FBAPP
predicates. Because of the widespread
distribution of control into the semantics
of primitive functions, for which no proof
steps need then be given, APL verifications
tend to be, just as their counterpart
APL programs, shorter and more
analytic than equivalent FBAPP program
verifications.

APL and Architecture

The form of the FBAPP languages
follows closely the structure of the
computers that prevailed during their
inception. They have the nice property
that one may often optimize machine
performance of their compiled programs by
transforming FBAPP programs to other FBAPP
programs. Control of the computer is more
easily exercised with programs in these
languages than with APL, since the latter
is more independent of current machines.
For many programs this control over the
target machine performance is quite vital,
and APL couples more weakly to the standard
computer than does FBAPP.

However, new array processing computers
are beginning to appear and, had they
been standard 20 years ago, APL and not
FORTRAN would have been the prototype of
language development. I often wonder at
what descriptive levels we would be
programming today had that been the case!
Since it was not the case, we should not
throw out or limit APL. We must seek ways
to match it to the common computer. We
must design compilers as well as computers
that fit APL better.

More Cost-Effective than BASIC

Cost is an important issue in the
instructional process. An APL computer
system currently costs about $10K per
terminal, about twice the cost of a BASIC
system. As APL system designs stabilize
and integrated circuitry costs drop, the
two figures will coincide at or near the
cost of a contemporary terminal. However,
even now the APL system is cheaper than
BASIC systems for equivalent work loads
because one can do more than twice as much
with APL in a given period of time than
with BASIC!

Let me mention in closing two additional
issues regarding the use of APL in
an introductory computer science course.
First, most university computer scientists
don’t really know APL. They haven’t
appreciated what it means to think in APL
— to think about parallel operations in
arrays and to distribute and submerge
explicit looping among its primitive
functions. I am reminded of the difficulties
many math departments experience when
they try to replace calculus by a fine
math and combinatorics course as the first
meat and potatoes offering by the department
to the university. However at Yale
we have found that faculty outside the
software milieu — in theory, for example
— pick up APL quite fast and prefer it to
FBAPP. I am sure the same is true elsewhere.

The second issue is of a different
kind. I am firmly convinced that APL and
LISP are related to each other along an
important axis of language design and that
acquiring simultaneous expertise in both
languages is possible and desirable for
the beginning student. Were they unified,
the set of tasks that succumb to terse,
flexible and expressive descriptions will
enlarge enormously without overly increasing
the intellectual burden on the student
over his initial 16 week contact period.

Above all, remember what we must
provide is a pou sto to last the student
for 40 years, not a handbook for tomorrow’s
employment.

First appeared in SIAM News, 1977-06.