APL: The Language Written in Its Own Alphabet

Zusammenfassung

Kenneth Iverson spent the late 1950s developing a mathematical notation for manipulating arrays of data — a notation so terse and precise that it could express in a single line what FORTRAN required a page to describe. He called it APL. Almost nobody uses it today. But the ideas it pioneered — operating on entire arrays at once, without explicit loops, using functions as first-class objects — became the foundation of NumPy, MATLAB, R, pandas, and the quantitative computing infrastructure that now underlies financial markets, scientific research, and machine learning. APL’s descendants run the world while APL itself is regarded as a historical curiosity and a test of intellectual nerve.

The Notation Before the Language

Kenneth Eugene Iverson was born in 1920 on a farm in Camrose, Alberta, Canada — a setting about as far from computing as one could be in 1920. He was a capable student who won a scholarship to Queen’s University, interrupted his studies during World War II, and eventually made his way to Harvard, where he completed a PhD in applied mathematics under Howard Aiken in 1954.

Aiken, who had built the Harvard Mark I in 1944, was one of the grand old men of computing, and his department was one of the few places in the 1950s where computing was taken seriously as an intellectual discipline rather than merely an engineering problem. Iverson joined the Harvard faculty after completing his doctorate and stayed for six years, teaching courses in computing. He found that existing mathematical notation was inadequate for describing computations clearly. The symbols for loops, conditionals, and data transformations were either absent or inconsistent across textbooks and papers. He wanted a notation as precise and compact as algebra — something a professor could write on a blackboard without ambiguity and a student could read without constant reference to a glossary.

By the late 1950s, Iverson had developed what he called simply a notation — a personal tool for writing down computational ideas. It used Greek letters, special symbols, and a set of operators that worked on arrays of numbers rather than individual values. The same symbol that would add two numbers together could, without any modification, add two matrices together, or add a scalar to every element of a vector. The notation was polymorphic: operators operated on data of any rank, and the rank of the data determined the rank of the result.

He used this notation in teaching. Students who learned it found they could express algorithms in a fraction of the space required by other methods. Whether they could read each other’s work was a different question.

“A Programming Language” (1962)

In 1962, Iverson published a book titled A Programming Language — the initials of the title giving the language its eventual name. The book was not, initially, a programming language in the practical sense: there was no implementation, no computer that would run APL programs. It was a mathematical argument that a unified notation for computation was possible and useful.

The book described APL’s core characteristics: primitive operations on arrays, a small set of symbols with precisely defined behavior on arrays of any shape and rank, and the ability to combine primitives into expressive compound operations. A single APL expression could sort an array, compute a running sum, generate the outer product of two vectors, or perform matrix transposition — operations that would each require a loop (or a library call) in any other language of the era.

The book attracted the attention of IBM. Iverson joined IBM Research in 1960, before the book’s publication, and found an environment hospitable to unconventional thinking. The 1962 book circulated within IBM and in the academic community, but APL remained a notation — a tool for thought — rather than a language one could run.

The APL Keyboard and the IBM System/360 (1966)

The transition from notation to runnable language required solving a practical problem: the symbols. APL used dozens of characters — ∘, ⍺, ⍵, ⌽, ⍉, ∊, ⍳, ↑, ↓, ⍴ — that appeared on no standard typewriter or terminal. Special APL keyboards had to be designed, with the symbols silk-screened onto the keys alongside their ASCII equivalents.

The first APL implementation ran on the IBM System/360 in 1966, developed by Iverson, Adin Falkoff, and Larry Breed at IBM’s research division. The implementation included an interactive interpreter — a program that accepted APL expressions, evaluated them immediately, and returned results. This was not yet universal in 1966; many computing environments still relied on batch processing, submitting card decks and waiting hours for output. APL’s interpreter made it ideal for the time-sharing systems that were emerging in the late 1960s: users at remote terminals could submit APL expressions and get immediate results.

IBM offered APL as a time-sharing service through the 1960s and 1970s. Businesses could dial into IBM’s APL service, rent time by the minute, and perform financial calculations, statistical analyses, and data transformations interactively. In an era before spreadsheets, APL was the tool that let a financial analyst ask arbitrary questions of a dataset without waiting for a programmer to write a custom program.

The APL keyboard became iconic — a symbol of the language’s demanding character. Sitting down at an APL terminal meant encountering a sea of unfamiliar symbols on keys otherwise occupied by standard letters and punctuation. The keyboard was the physical manifestation of APL’s intellectual barrier to entry.

The APL One-Liner Tradition

APL’s terseness gave rise to a cultural practice: the one-liner. An APL one-liner is a complete program expressed in a single line — sometimes a single expression — that performs a significant computation. The canonical example is the program that generates the first N prime numbers, expressible in APL in roughly fifteen characters using the outer product operator and a reduction. Conway’s Game of Life can be implemented in a single APL expression. The one-liner became a measure of APL mastery, a demonstration that the programmer had internalized enough of the language’s primitive operations to compose them fluently. It was also, critics noted, precisely the reason APL code was unreadable to non-practitioners: the same compactness that made one-liners impressive made programs difficult to maintain.

Turing Award and the Array Paradigm

Kenneth Iverson received the ACM Turing Award in 1979 for his work on APL. The citation recognized “his pioneering effort in programming languages and mathematical notation resulting in what the computing field knows today as APL.” By 1979, APL had spread through universities, financial institutions, and research laboratories — a community small by the standards of COBOL or FORTRAN, but deeply committed to the language’s approach.

The intellectual contribution the award recognized was not the language specifically but the array-oriented programming paradigm: the idea that the natural unit of computation is not the scalar value but the array, and that language primitives should operate on arrays directly. In most languages, adding two vectors required a loop:

for i in range(len(a)):
    result[i] = a[i] + b[i]

In APL, the same operation was expressed as:

result ← a + b

The + operator on arrays performed element-wise addition without an explicit loop, because the operation was defined to apply to entire arrays. This was not syntactic sugar — it reflected a different computational model, one in which the programmer thought in terms of transformations applied to collections rather than operations applied to individual elements.

The implications for performance would become significant decades later, when hardware architectures with vector processing units — and later GPUs — could execute array operations in parallel across multiple elements simultaneously. A language that expressed computation as array operations could, in principle, exploit that parallelism without the programmer’s explicit instruction.

The Descendants: From Wall Street to NumPy

APL itself was never adopted widely. Its symbol set, its learning curve, and its one-liner culture created barriers that most organizations were unwilling to overcome. But its ideas spread through a series of languages that adapted the array paradigm to different needs and audiences.

A+ was developed at Morgan Stanley in the late 1980s by Arthur Whitney and others, based on APL but adapted for the demands of financial computing — large datasets, complex aggregations, time-series analysis. It became the foundation of much of Morgan Stanley’s quantitative infrastructure and remained in use at the firm for decades.

J was developed by Iverson himself, with Roger Hui, starting in 1990. It was explicitly a reimagining of APL in ASCII characters — every APL symbol could be expressed as a digraph using ASCII characters, eliminating the keyboard problem. J retained APL’s essential array-orientation and added functional programming features. It remained a language for specialists and enthusiasts, but its development showed that Iverson continued to believe in the paradigm’s essential correctness into his eighties. Iverson died in 2004; the J community continues to maintain the language.

K, developed by Arthur Whitney in 1993 and commercialized through his company Kx Systems, was an even more radical compression of APL’s ideas: a language in which the entire standard library fit in 600 lines of code, programs were measured in kilobytes, and performance on time-series data was, for many workloads, unmatched by any other language. K became the foundation of the Q language and the kdb+ time-series database, which became the dominant platform for high-frequency trading infrastructure. The financial industry runs, to an extraordinary extent, on ideas derived from a 1962 book by a Canadian mathematician.

BQN, released publicly by Marshall Lochbaum in 2020, represents the most recent attempt to modernize the APL paradigm: a fresh syntax, careful attention to the language’s theoretical coherence, and features influenced by modern functional programming research. It has attracted a small but active community.

MATLAB (1984), NumPy (2005), R (1993), and pandas (2008) represent the mainstream adoption of array-oriented computing. Each of these systems implements the core APL insight — array operations as primitives, broadcasting and element-wise arithmetic as defaults — in a syntax accessible to scientists and engineers without APL backgrounds. NumPy’s ndarray is Iverson’s array made available to millions of Python programmers. Every machine learning framework that operates on tensors — TensorFlow, PyTorch — is implementing the array paradigm Iverson described in 1962.

Why Nobody Uses APL (and Why That Doesn’t Matter)

APL’s failure to achieve mainstream adoption is instructive.

The language suffered from three reinforcing problems. First, its symbol set made code difficult to enter and read without specialized equipment or extensive memorization. Second, its terseness meant that complex programs were extremely compact — a property that experts valued and that made maintenance by non-experts nearly impossible. Third, the cultural norms of the APL community around one-liners and maximal compression actively discouraged the kind of readable, documented code that organizations need for long-lived systems.

The Readability Trap

APL’s defenders argued — correctly — that terse, symbol-dense code was no harder to read for an APL expert than FORTRAN was for a FORTRAN programmer. Expertise is always required; it is only the nature of the expertise that differs. The practical counterargument was that APL expertise was rarer, more slowly acquired, and less transferable across organizations than expertise in more widely-used languages. The expected cost of maintaining an APL codebase — over a time horizon measured in years and accounting for staff turnover — was higher than the cost of maintaining equivalent code in a language with a larger practitioner community. Whatever APL’s theoretical elegance, organizations found the talent economics unappealing.

The more interesting question is whether APL’s ideas were ahead of their hardware. In the 1960s and 1970s, computers executed instructions sequentially; array operations were implemented as loops internally, offering no performance advantage over explicit loops in other languages. The elegance was conceptual, not computational.

In the 2010s and 2020s, with GPU computing and hardware vector units standard in scientific and machine learning workloads, array operations execute in parallel across thousands of cores simultaneously. A framework that expresses computation as tensor operations — and PyTorch, TensorFlow, and JAX all do — can exploit this parallelism automatically. Iverson’s insight, that the array is the natural unit of computation, turned out to be correct for hardware that did not yet exist when he had it.