Hero image for "APL's Symbols Needed a Special Typewriter Ball Before They Needed a Theory"

APL's Symbols Needed a Special Typewriter Ball Before They Needed a Theory


I've written before about how APL's glyphs encode a philosophy, not just a shorthand (April 15, April 22). What I hadn't fully reckoned with is how much of that philosophy was downstream of a piece of IBM hardware nobody remembers anymore: the Selectric typeball.

Kenneth Iverson wasn't designing a programming language when he invented the notation that became APL. He was at Harvard in the late 1950s trying to describe algorithms on paper clearly enough that mathematicians could follow them, and he published the result in his 1962 book A Programming Language — the source of the name (Bloghints). It wasn't until he joined IBM in 1960 and, with Adin Falkoff, used the notation to formally describe the System/360 architecture that anyone thought about running it (Bloghints). Larry Breed and Dick Lathwell, working with Roger Moore at I.P. Sharp Associates, built the interpreter, and by 1966 IBM had a working time-sharing system called APL\360 — the same system a recent clean-room reconstruction project traces its lineage back to, checking its own behavior character-for-character against IBM's original 1970 manuals (Software Wrighter Lab Blog).

The Keyboard Decided What the Language Could Say

Here's the part I find genuinely delightful: users typed on IBM 2741 terminals, which used a Selectric mechanism, and IBM simply swapped in a special APL typeball so the terminal could print the symbol set (Bloghints). Characters that didn't fit on the ball got produced by overstriking — type one glyph, backspace, type another, and a new symbol appears on the page (Bloghints). That's not a footnote. It means the density of APL's notation wasn't purely a mathematical ideal chasing elegance — it was also an ideal bumping up against the physical limit of how many distinct marks a typewriter ball could carry, and overstriking was the hack that let the symbol set grow past that limit. Iverson's Turing Award lecture, "Notation as a Tool of Thought," makes the philosophical case: compress the small ideas into single marks so your head has room for the big ones. But the typeball is the part of the story where theory met the shop floor, and the shop floor talked back — a tension a long-run survey of indexing notation frames as part of a much older arc, tracing array-addressing ideas back to Yushchenko's Address Programming Language decades before Iverson formalized anything (arXiv).

Rebuilding the 1968 System Shows What Was Actually Essential

A recent clean-room project makes the archaeology literal. A Rust-based reconstruction called sw-apl aims to reproduce APL\360 as closely as the original 1968 manuals allow — the traditional glyphs typed as Unicode, the six-space indent convention, function definitions behind the ∇ prompt, flat arrays only, no nesting, no each operator (Software Wrighter Lab Blog). Its author has also built two other APL-descended systems — a tiny ASCII-keyword array language for an FPGA soft CPU, and a nested-array, autograd-equipped language aimed at machine learning tensors (Software Wrighter Lab Blog). Laying all three side by side produces a useful observation: every later addition to APL — nesting, nested nesting, each, nested-array generalizations of every primitive — is individually defensible, but the 1968 original is the version where "you can see the whole idea at once" (Software Wrighter Lab Blog). That's a claim worth sitting with if you've only ever encountered APL through a modern Dyalog tutorial loaded with decades of accreted power. The notation got denser over time in a different sense than the typeball forced — not more symbols per character, but more meaning packed into each symbol as ranks and nesting got added.

Why This Still Matters for Array Programming Today

The comparative-language research reinforces that APL's compression strategy wasn't a one-off accident of 1960s hardware; it became a lineage. A 2018 ACM workshop paper, "A Rosetta Stone for Array Languages," built a shared test suite and compiler toolchain (code generation targeting C, SaC, Python, APL, and Julia) specifically to let researchers compare how different array languages express the same algorithms (Zenodo). That kind of cross-language test harness only makes sense if you accept Iverson's original premise — that notation itself shapes what you can compute, not just how you write it down — and the arXiv survey's long view of addressing schemes suggests that premise was being worked out, in fragments, long before APL gave it a name (arXiv).

Put together, these threads suggest the interesting question isn't whether dense notation was a good idea — sixty years of descendants answer that — but which density was load-bearing. The typeball forced economy of symbol count. Iverson's theory forced economy of thought per symbol. Those two constraints aren't the same thing, and the systems that have aged best, like the 1968 original sw-apl tries to resurrect, are the ones where both pressures pointed the same direction at once (Software Wrighter Lab Blog).