Note: Following are personal recollections of APL, from the early 1980s when I worked with APL in IBM. (I was especially friendly with one APL developer at the Thomas J. Watson Research lab in Yorktown Heights NY, Alan Tritter.) -- I understand that, in the intervening two decades, "some things have changed", both with APL and also PASCAL. Therefore, what I have written may not accurately reflect the situation of APL (or PASCAL!) at the start of the new millennium.
APL is a computer programming language unlike any other. This is obvious from the first instant you see an APL program: An APL program doesn't even look like other computer programs! --APL programs look more like algebraic formulas.... One Internet dictionary of programming languages describes APL thus: "Famous for its enormous character set, and for being able to write whole accounting packages or air traffic control systems with a few incomprehensible key strokes."(http://public.logica.com/~stepneys/cyc/p/prog.htm) (The example APL program shown, above, is explained in detail, below)
APL is a computer programming implementation of a notation Kenneth E. Iverson, while he was a professor at Harvard, in the late 1950s, invented ("Iverson notation"), to facilitate succinctly describing certain mathematical propositions, and also to help teach mathematics (my view on this latter item, below). The notation came first; only later was the notation implemented as a computer programming language [APL], after Iverson came to IBM, in the early 1960s.
To say that APL is unlike any other programming language may be an understatement. No ordinary language words are used in APL -- not even the almost ubiquitous computer word: IF. APL even requires a special computer keyboard, since much of the syntax consists of Greek letters and specially invented characters. Back in the time before television-like video display monitors became the normal way for computers to communicate with users, in the days of printing ("TTY", i.e.: "teletype"...) computer terminals that looked like over-large IBM Selectric typewriters, one needed a special "type ball" to print the APL.... [Author notes: (1) My experience with APL ended over 20 years ago; I hear that, since then, things have changed: persons no longer need to use special keyboards, and "word-size" syntactic elements have been introduced, even "IF..." constructs. I have no idea to what extent the original radiant purity of the language may have been compromised. (2) APL2 is an extension of APL, originally released by IBM, ca. 1982. The main difference, if I remember correctly, is that it implements: "nested arrays", i.e., an element in an array can be itself an array in APL2.]
APL's most obvious attribute is: succinctness. The APL community newsletter is (or at least used to be...): "QuoteQuad" (named after the APL print function[fn.24], which is a rectangle with a single quote mark at top center). Each issue contained a programming puzzle. In most computer programming languages, the challenge might be to solve the puzzle in the fewest lines of code. In APL, it is generally a given that the solution will be one line of code: The challenge is to solve the problem in the fewest characters!
The heart of APL is a set of powerful built-in functions, which can be combined by indefinitely "nesting" functions, as the result obtained from evaluating one function becomes a parameter for the next higher-level function. Such "functional composition" is not unique to APL; most programming languages provide this facility. But the wordiness of other programming languages tends to limit use of this feature in practice; APL's succinctness, on the other hand, tends to encourage its use -- APL's detractors say: too much use, i.e., abuse. APL is as succinct as algebra, but with a powerful set of functions that do far more than add, subtract, multiply, divide, exponentiate and take roots of numbers (some APL functions take other functions as parameters!).... APL functions can be applied to multi-dimensional arrays of arrays [of arrays...], as easily and succinctly as they can be applied to atomic items. To add a million dollars to everyone in the world's bank account, simply define an array with an element for every account in the world, "A", and add a million to each element in the array: "A <- A + 1000000". (Clearly, APL lends itself naturally to massively parallel processing!)
PEDAGOGY. Why is APL a powerful teaching tool? Surely there are many reasons. The one which most impresses me, however, is that APL makes numbers "move": APL turns the symbols in its character set into actors in user-created computational dramas. (I have often said: "The APL symbols are like friendly little animals that want to play with you.") When I was in school, I did not find any interest in trying to demonstrate that the stolid lump on the left side of an equals sign was equivalent to the stolid lump on the right side of the equals sign, especially when I knew the teacher already knew whether the two stolid lumps were equivalent, but (s)he wouldn't tell me, so that (s)he could test me to see if I could figure out what truth (s)he was withholding from me. --APL, on the contrary, succinctly and easily implements such things as "recursive functions", so that the learner can command -- choreograph? -- numbers to do various things of interest to the learner, and then watch to see what the numbers actually do.
An APL detractor will immediately demur: "But to enable persons to play with possibilities is just what all computer programming languages enable people to do!" And the demurral is correct, but it misses the point. In the verbosity of most programming languages, the "forest" gets lost in the proliferation of "trees": The wordiness of the implementation tends to foreground itself vis-à-vis the "play" of exploring computational possibilities. I propose that APL would be a delicious "treat" for many mathematically oriented students, and, even more important: that APL should intrigue at least some not mathematically oriented students to become interested in math! (--Contrast with those opposing "stolid lumps", which don't do anything even if you poke at them -- indeed, that's the whole point of them, to make the student do a lot of jumping through hoops to demonstrate that if either of the stolid lumps ever did rouse itself to action, it could morph into the other stolid lump, but everybody knows neither lump ever will, so why bother?)
I have said that most computer programming languages are less succinct or imaginatively evocative than APL. One antipodal opposite is the PASCAL programming language. Not only is PASCAL numbingly wordy. I used to describe it as a: "fascist programming language", because it is dictatorially rigid. In PASCAL, nothing can metamorphose into anything other than what it already is, nor is the programmer free to go where (s)he wants. The first constraint is called "strong typing": An integer PASCAL variable can never contain anything but an integer value, whereas any APL variable can contain, now an integer, now an array of character strings, now an array in which some of the elements are themselves arrays [of anything, including whole APL programs...].... The second PASCAL constraint is called: "GOTO-less programming". I once expressed my feelings about the evil of GOTOs (which, it is true, can be used to make a computer program as cleanly structured as a ball of yarn after a cat has worked on it for a day) -- I used to express my feelings on this matter, by saying that I too want to eliminate GOTOs from computer programs, and I also want to eliminate what PASCAL fans would put in their place: "IF... THEN... ELSE..." and "DO... WHILE..." constructs! I want to replace as much as possible of this conditionally executed coding diaspora, by succinct, assertoric computations! To some degree, one can do this in most programming languages; APL entices one to go out of one's way to see how pithily elegantly one can do it (yes, that means possibly to overdo it).
A frequently heard argument against APL is that 80% of computer programming is maintenance, and APL programs are unmaintainable: Even from the beginning, no one but the author can understand the code, and, after some time has passed, even (s)he can no longer understand it. Of course the detractors of APL conveniently forget to mention that non-trivial programs written in any language tend to become, over time, what Joseph Weizenbaum (1978) called: "incomprehensible programs". And surely one would want to be careful in letting programmers' imaginations run amok with "mission critical" applications such as air traffic and nuclear power plant control systems -- i.e., the non-APL applications to which Weizenbaum originally applied his admonitory appellation....
For many purposes, however, as I once read, it's cheaper to (a) write an APL application 4 times to do a given function -- each rewrite being necessitated either by changes in functional requirements or by no one any longer being able to figure out how the current implementation works --, than to (b) write and maintain one program in another programming language to accomplish the same tasks over the same span of time. --Another perspective on APL's productivity potential was offered by an IBM Research physicist, who told me: "Before APL, there was a department of programmers who wrote programs for the physicists and chemists; with APL, scientists write their programs themselves." APL is what Ithiel de Sola Pool called a "technology of freedom": APL puts the power of computer programming directly in the hands of non-programmers![fn.22] (I hear that, today, APL is popular among actuaries, so that some think the acronym means: "Actuarial Programing Language".)
To conclude this little overview of what APL is and why APL is important, I wish to return to the inflammatory word I used to characterize PASCAL: fascist. If PASCAL is fascist, APL is anarchist. I tend to prefer anarchists to fascists. Less flippantly, I prefer nourishment of free play of imagination to authoritarianly imposed rigidity. I used to say that I could generally tell whether I would or would not get along well with a programming person, by learning their answers to two questions: (1) "Do you like/dislike PASCAL?" (2) "Do you like/dislike APL?"
Sadly, the anti-APL faction seems today, some twenty years later, to have won the war by the simple technique of distraction (just doing something else...[fn.23]). Ken Iverson's at times breathtakingly beautiful conception languishes in near-oblivion (the only programming language desideratum of any importance is to make everything "object-oriented", but, of course, in Kafkaesque C++, not, e.g.: Smalltalk, which is a more imaginatively evocative and elegant object-oriented programming language!). Unlike that other old-time IBMer, Charles Goldfarb's, perhaps even more epochal invention: SGML, APL has not even been mendaciously coopted by its enemies (to date, no XML APL-equivalent has made the headlines, nor is there reason to expect one ever will...). [Author's note: I am not familiar with recent developments, such as the J programming language, which may be relevant here.]
|See IBM poster: "How to Stuff a Wild Duck".
Learn about Curta mechanical calculators.
Read my computer aphorisms & data processing memories.
SGML document introducing you to SGML.
Return to shorter thoughts (McLuhanesque probes) page.
|Return to Brad McCormick's resume.
What's new on this website?
Go to website Table of Contents.
Return to Brad McCormick's home page.
Go to site map.