APL and APL/360: Turning Mathematical Notation into Interactive Computing

APL began as a notation for describing procedures and systems, not as a plan to create a terse programming language for hobbyists. Kenneth E. Iverson developed a mathematical notation while working on ways to describe data-processing systems. At IBM, Adin D. Falkoff and other colleagues helped turn that notation into an interactive language that could run on IBM System/360 systems. APL’s distinctive symbols were the visible part of a deeper design: operations on whole arrays, a compact set of primitives, and a language that users could extend with functions of their own.

Its history is often flattened into the claim that APL was simply a strange language with an unusual keyboard. That misses both its original purpose and its computing environment. The notation addressed problems of expressing transformations clearly; APL/360 made those transformations executable in an interactive session; and special terminals made the glyphs practical to enter. These pieces developed over time and should be treated separately.

Iverson’s notation preceded APL as an interactive system

Iverson’s book A Programming Language, published in 1962, introduced a notation intended to describe algorithms and information-processing procedures. Its use of mathematical symbols was not decoration. The notation tried to give common operations concise representations and to make arrays and transformations explicit. The reader could follow a calculation as a formal object rather than translate every step into a machine-oriented instruction sequence.

The first purpose was partly educational and descriptive. A notation that could express a computer’s structure and behavior could also help explain the machine to students and engineers. Falkoff and colleagues later used APL to describe the IBM System/360 architecture. This project connected notation to system design, but it does not mean the whole System/360 was implemented in APL or that the language was an operating system.

At IBM, the notation acquired a second role. Researchers and programmers explored how to evaluate its expressions on actual machines. This required decisions about character representation, parsing, storage, functions, and user interaction. A printed mathematical notation could tolerate ambiguity that an executing interpreter could not. APL’s history is therefore both a language story and an implementation story.

Array operations changed the level of expression

APL provided primitives that operated on arrays, with scalar, vector, and higher-dimensional data handled within a coherent notation. Instead of writing a loop for every element-wise operation, a programmer could often express a transformation over an entire vector. Reduction and scan operations gave concise forms for aggregation and cumulative work. The exact set of operations developed across versions, so a description of one implementation should not automatically be applied to every APL dialect.

The result was expressive density. A short APL expression could represent a computation that took many lines in a conventional language, especially when the problem naturally involved arrays. Density is not the same as clarity for every reader. The notation was powerful for trained users and difficult for people without access to the special character set, documentation, and conceptual model.

The design did not eliminate the need to reason about data. Array shape, type, ordering, and edge cases still mattered. A single expression could conceal a large intermediate result or encode a subtle assumption. Experienced APL programmers used the language’s primitives to make intent direct, but a compact expression was not automatically self-explanatory or efficient on every hardware generation.

IBM System/360 supplied a practical target

APL/360 was an implementation for IBM System/360 systems. Falkoff and Iverson’s 1967 paper, The APL/360 Terminal System, documents an environment in which users interacted with the language through terminals rather than submitting only batch jobs. This was significant in an era when many computer installations treated program preparation, compilation, and execution as separate operations mediated by cards, operators, and queued jobs.

Interactive use changed the feedback loop. A user could enter an expression, inspect a result, revise a function, and continue in one session. This suited exploratory computation, teaching, data analysis, and the iterative construction of functions. It did not mean the system had no resource limits, that every IBM installation offered the same service, or that APL displaced batch computing. Time-sharing capacity, terminal availability, memory, and local system administration still determined who could use it and how.

The System/360 context also mattered for portability. The family offered a compatible architectural model across a range of machines, but APL/360 was still a specific software system with its own representation, runtime, and host requirements. A program that depended on system commands, files, terminal features, or a local workspace convention could require adaptation elsewhere.

The keyboard was part of the language’s infrastructure

APL used symbols not ordinarily found on a standard typewriter keyboard. Practical systems therefore needed keyboards, type elements, or terminal configurations capable of entering and printing those characters. The APL/360 terminal-system paper describes the interaction model and the specialized equipment around it. Character encoding and display were not trivial afterthoughts: the language’s notation had to survive input, transmission, storage, and hard-copy output.

That requirement created an adoption barrier. A user could not assume that a generic terminal or printer would render every symbol. Incompatible character sets also made source exchange more difficult than exchanging plain ASCII code. Different APL systems made differing choices about glyph sets and keyboards, which is one reason visual similarity does not guarantee that source files move unchanged between installations.

The keyboard also influenced the experience of programming. APL users learned a mapping between keys and mathematical operations, then combined the primitives into expressions and named functions. This was a real interface discipline, not a trick for compressing code. The visual language made certain operations prominent and pushed other features into the background.

APL’s users could build domain vocabularies

APL functions could be named and composed, letting organizations create higher-level operations in terms of lower-level primitives. This supported domain-specific tools for actuarial work, business analysis, scientific computation, and education. The same feature could make an application concise while making it dependent on a local function library or workspace.

The distinction between language and system conventions is important. A user might rely on a particular editor, workspace persistence model, file interface, or vendor extension. Those facilities shaped the lived experience, but they were not all universal properties of the APL language. A historical account should identify whether a claim concerns the notation, a standard, the APL/360 system, or one vendor’s implementation.

APL’s expressive power also supported interactive exploration. Rather than plan a complete batch run before seeing results, users could work through data and refine a calculation at the terminal. That made APL attractive for analysts who needed to ask follow-up questions. The language did not invent interactive computing, but it provided a compact model well suited to it.

Adoption and criticism had the same source

The features that made APL concise could make it opaque to newcomers. Heavy use of symbols, overloaded operations, and nested expressions could compress a great deal of meaning into a line. This was effective when author and reader shared a vocabulary; it could be discouraging when code was passed to someone without that background.

Some criticism focused on readability, while some praised the language’s mathematical directness. Both reactions can be correct. A language’s usefulness depends on its users, tasks, tools, and community practices. Teams that documented functions, chose names carefully, and used the array model deliberately could exploit APL’s density. Teams that treated brevity as the only goal could create code that was hard to maintain.

Hardware and markets also influenced its spread. Dedicated terminal equipment cost money, and APL services depended on a computing center. Later small systems put APL implementations closer to users. IBM’s 5100 family, for example, offered APL as one of its built-in language options, but that did not make every APL program portable or remove the specialized tradition surrounding the language.

A lasting idea, not a universal replacement

APL’s broader influence can be seen in array-oriented languages and in the ongoing interest in interactive, concise computation. J and other descendants made different tradeoffs in notation and character handling; scientific and data languages adopted array operations without reproducing APL’s entire model. Influence should not be confused with direct inheritance: a later language may share an idea while making different choices about syntax, types, runtime, and libraries.

APL also provides an instructive example of co-design among language, hardware, and user interface. Its symbols shaped the keyboard; the terminal shaped interactive use; the machine shaped implementation constraints; and communities shaped the vocabulary around the language. Treating the language file alone as the complete technology would miss the environment that made it useful.

The strongest historical evidence comes from Iverson’s original book, the APL/360 system paper, and the Computer History Museum’s preserved materials. These sources show both the notation’s intention and the engineering required to make it executable. APL did not become the default language of all computing, but it demonstrated that array-first expressions and immediate interaction could support serious work on commercial machines.

Related:

Sources: