Discovering APL

From APL Wiki
Jump to navigation Jump to search
A brief review of APL, its origins and what makes it distinctive. By Stephen Taylor (lightly edited for APL Wiki).

Contents

Origins

Early programming languages were designed to control what computers do. At Harvard in the 1950s Ken Iverson was revising traditional mathematical notation. He wanted a consistent language for describing operations on arrays, a notation a machine could interpret.

Iverson was a key member of the early computer science community. At Harvard with Howard Aiken he taught the world’s first classes on computing. When he published his math notation, he titled the book A Programming Language (Wiley, New York, 1962). His teaching assistant at Harvard, Fred Brooks, author of The Mythical Man-Month, was IBM’s project manager for the development of OS/360, its first multi-tasking operating system. (OS/360 was the first operating system ever described formally — in Iverson notation, of course.) Iverson also went to IBM, who made him a Research Fellow, and implemented his notation on an 1130 computer, where it was dubbed APL after the title of his book. APL\1130 was providing personal computing to a community of users well before OS/360 came to life.

The 1960s and 70s saw many efforts to produce VHLLs (Very High Level Languages) that would lower the skill requirements for programmers, a general strategy of industrialisation. The APL community played no part in this. Iverson stressed the importance of APL as a “tool of thought”, a notation to help humans describe and solve complex problems. We were not trying to make everyday programming easy; we wanted to solve harder problems faster. (The complete code for calculating the mean of a list of numbers requires 3 characters.) Ironically, experience shows APLs are easier for novices to learn than conventional programming languages.

APL never fitted comfortably into IBM’s product line, but was widely used by managers within the company. Until PCs became widely available, IBM had more employees writing APL than any other company. In the 1970s and 80s, educators, mathematicians, language designers and programmers combined to give the APLs cult status.

In the 1980s and 1990s the interest of an increasingly professionalised IT community shifted to problems (writing GUIs, and formal methods for developing software) to which APLs had little to contribute. Formal software development methods especially deprecated the use of APLs, by distinguishing analysis, design, programming and testing as separate activities and embedding them in elaborate ‘methodologies’. Programming represents such a small fraction of these ventures that no plausible improvement in programmer productivity could justify the high skill levels associated with APL.

Despite extraordinary proven productivity, APL was dropped from company after company, largely on theoretical grounds that argued for compliance with IT strategies. Until the advent of Extreme Programming (XP) and the Agile Alliance, few saw that programming is a design activity, and analysis often best done iteratively. In this period the APLs flourished only where results consistently outweighed IT theory, for example, in investment bank trading rooms.

As support now ebbs generally from the Software Engineering movement, the APLs remain the sharpest tool in the box, with a strong tradition of agile development.

Why vector languages?

Distinct from object-orientation, currently the most popular abstraction paradigm for software developers, array-orientation is an older paradigm, closely associated with functional programming, that offers different powers. Just as Vector languages have been extended to facilitate object-oriented programming, so array-oriented extensions are available for OO languages such as Java and C++. From the Vector languages, OO programmers can learn powerful techniques.

Interpreters for the Vector languages have always had managed code (managing machine details), to let the programmer focus on more abstract issues. Their low housekeeping and interactive development environments make them languages of choice for many programmers pressed for time. Not surprisingly, Vector languages have a long association with agile or lightweight software development.

Arrays and lists are what Vector languages do best. Nowhere is this more evident than in processing the long time-series created from financial market data-feeds. On these problems Vector language Q and its kdb database routinely outperform conventional databases by factors of 20-50.

An example of programming in Q demonstrates how Vector languages change the way you think, even about scalar (non-array) problems. A recent review of .NET language implementations compared hand-coded solutions to a standard 'benchmark' programming problem. The reviewer's solutions to this scalar problem all ran to about 400 lines of code and took 9-20 seconds to execute on an 800MHz PC. A solution in Q dropped execution time by one order of magnitude and code volume by two: four short lines of primitive Q code, no library calls.

The special powers Vector languages have with arrays make it easy to see emerging patterns. For this reason they have long been valued by educators, by scientists needing quickly to explore the implications of a theory, and by mathematicians, for whom they were, after all, first invented.

A Shocking Brevity

APL (A Programming Language) takes its name from the eponymous book in which Ken Iverson, then teaching mathematics at Harvard, introduced his revised notation for linear algebra. From Harvard he became an IBM Fellow. At IBM, ‘Iverson notation’ became A Programming Language, distinguished by a shocking brevity.

This brevity originates in

  • applying functions to arrays of values, abstracting away the work of controlling loops and counters;
  • single-character glyphs used to represent primitive functions;
  • weak data-typing, so that a small number of powerful primitive functions generalise over many kinds of data.

It leads to a fast, informal and exploratory style of programming quite unlike the ‘waterfall’ approach of Software Engineering.

Unusual Symbols

The single-character APL glyphs have frequently been cited as evidence of APL being unintelligible, or “a write-only language”. This can also be said of any unfamiliar language (do regular expressions attract similar comment?)

The glyphs are largely unnecessary and can easily be replaced by reserved words. This can be helpful for a novice who wishes to separate learning syntax and semantics from mastering a keyboard mapping. However most writers prefer the ‘power shorthand’. For example:

+÷≢

rather than

sum divide tally

The density of APL expressions helps writers identify and accumulate abstractions, a crucial part of refactoring.

It is possible to write as unintelligibly in APL as it is in Java or English. But APL’s great expressiveness also allows solutions of great simplicity and clarity.

APL and Typography

All writing systems and notations are bound closely to inscribing technologies. For example, the glyphs of the earliest Greek and Viking alphabets were formed by the straight strokes of chisels. The curves and serifs of the Latin majuscule, for which Trajan’s Column provides the paradigm, reflect a more advanced sculpting technique.

Each advance in inscribing technology first mimics and then adapts the glyphs it inherits. The writers of the mediæval and Renaissance churches started with letter forms designed for chisels, then adapted them to suit their faster pens. Thus in York Minster, the monk Alcuin devised what became the Carolingian miniscule, and Italy saw the creation of chancery cursive. When Gutenberg built a press such as Marco Polo had seen in China, his type was a simple copy of contemporary written pen forms. Later in Italy, printers thinned and lightened the black-letter forms to the light and elegant types of the Aldine Press.[1]

The APLs are part of this story.

Strictly Linear

An IBM group implemented as a programming language the mathematical notation Ken Iverson described in A Programming Language.

In that book, Iverson set out to revise and simplify traditional notation, which had evolved over the centuries as one mathematician after another improvised whatever seemed convenient to capture each new idea. They were constrained only by the limits of a pencil on a plane. Mathematicians invented, and printers followed patiently.

When Iverson, Falkoff and others first came to implement APL, Iverson’s notation was adapted to the strictly linear inscription of teletype terminals. But the interchangeable ‘golf-ball’ printing head of IBM typewriters and terminals (and later the Xerox ‘daisy-wheel’) made it possible to produce a linearised version of the glyphs used in the book.

Computing in the 1980s was dominated by the spread of cheap PCs with only ASCII Latin characters. Specialised mainframe APL terminals became a relatively expensive way to write programs. Although the Macintosh and its variable fonts appeared in 1985, it was not until late in the decade that an APL was available for it. On Macintosh and PC alike, writers of APL had to learn non-standard keyboard mappings to create their characters.

By 1990 several APLs had adapted their notation to the dominant inscribing technology. Nial used reserved English words; J paired ASCII characters to make 2-character glyphs; A+, J and K all exploit characters usually associated with punctuation, while Q mostly uses K's glyphs for monadic functions and reserved words for monadic functions.

Write On

As the inscribing technology changes, so do the writing habits. The spread of the simple typewriter made the use of ligatures, even in printed books, seem pedantic and antiquated. Æsthetics became aesthetics and to write mediæval came to seem, well, mediaeval. To write cafe instead of café became if not actually correct, at least forgivable. A generation grew up to drink caffè latte without being able to type it.

The wheel continues to turn. The Internet has spread and connected PCs across many linguistic systems and scripts. Operating systems now routinely support not just multiple fonts but multiple writing systems and keyboard mappings to use them. The PC on which I am writing this has its browsers configured to display HTML pages in Western European languages, in Turkish, Japanese and Korean.

After its initial fascination with graphic design, web design now looks more like typography. My mouse rests upon a mousemat that shows me how to key the extended Western Latin ASCII characters less easily reached from the keyboard. (Or see Bringhurst’s ingenious mapping in The Elements of Typographic Style[2] and my review of it.[3]) My girlfriend manages to use Macintosh and Windows mappings for Japanese without a diagram. I can usually manage the same for APL, but have a diagram above my monitor for when I can’t.

Signs of the times

Contemporary inscribing technology supports multiple languages and writing systems. (A Japanese web page will casually mix three to five different scripts.) The elegant and distinctive glyphs of APL are by no means the most exotic writing system my PC supports today.

Iverson insisted upon the importance of his notation as a tool of thought. Similarly, Paul Graham has written of coding as an essential part of exploration and design. The terse and distinctive signs of APL increase its utility, but only if they can be typed as well as written.

Recent technology made APL’s glyphs relatively inaccessible, and correspondingly less useful as a tool of thought. Current technology makes them once again accessible, and more useful than they have been for decades.

References

  1. An Essay on Typography Eric Gill, 1931, 5th edn 1988 Lund Humphries, London, ISBN 0 85331 509 4
  2. The Elements of Typographic Style Robert Bringhurst, Version 2.5, 2002, Hartley & Marks, Vancouver BC, Canada. ISBN 0 88179 132 6
  3. The Solid Form of Language Robert Bringhurst, 2004, Gaspereau Press, Kentsville NS, Canada. ISBN 1 894031 88 1 · Reviewed in Vector 21.2 “Liquid Mathematics”