Perlisisms: The 1982 Epigrams That Still Cut to the Heart of Programming

Alan J. Perlis, a Yale University computer scientist and the first recipient of the Turing Award, published a collection of 120 observations about programming in ACM's SIGPLAN newsletter in September 1982. He called them "Epigrams in Programming." Forty-four years later, they read less like historical artifacts and more like field notes from someone who understood what software actually does to the people who make it.

You can find the full collection at SIGPLAN Notices Vol. 17, No. 9, 1982 and various mirrors online, including a well-maintained version hosted at Yale.

What Perlis Was Doing

The epigrams aren't jokes, exactly, and they aren't aphorisms in the inspirational poster sense. They're compressed arguments, each one a tiny essay about what programming actually involves when you strip away the marketing language and the academic framing. Some are funny. Some are uncomfortable. Most are both.

Perlis wrote them during a period when programming languages were proliferating rapidly. FORTRAN, LISP, ALGOL, SNOBOL, APL, PL/I, and others were all competing for mindshare. The epigrams reflect someone watching this Cambrian explosion with clear eyes, trying to figure out what actually matters about the act of programming versus what just fills conference talks.

The Ones That Still Sting

Several epigrams have become so embedded in computer science culture that they're quoted without attribution. Epigram 54 warns about "the Turing tar-pit in which everything is possible but nothing of interest is easy." Every developer who has spent a week wiring together a microservices architecture has felt this in their bones.

Epigram 19, "A language that doesn't affect the way you think about programming, is not worth knowing," became the implicit argument for why learning Haskell or Lisp changes how you write JavaScript. It's also the reason functional programming concepts keep resurfacing in mainstream languages, from LINQ in C# to the stream APIs in Java.

Epigram 58 sorts programmers by how they handle complexity: "Fools ignore complexity. Pragmatists suffer it. Some can avoid it. Geniuses remove it." This remains a surprisingly useful hiring rubric. Watch how a candidate approaches a messy codebase. Do they add to it, endure it, simplify it, or eliminate the problem that created it?

The LISP Observations

Perlis had strong opinions about LISP, and several epigrams are specifically about the LISP community's relationship with its tools. Epigram 55, "A LISP programmer knows the value of everything, but the cost of nothing," became the standard criticism of LISP's elegant but sometimes wasteful abstractions. Epigram 49 compared abandoning assembly language to "the apple in our Garden of Eden," suggesting that any language that squanders machine cycles is committing a kind of sin.

These observations remain relevant as we debate Rust's manual memory management against garbage-collected languages. The tradeoffs haven't changed, only the hardware has gotten faster.

The Uncomfortable Truths

Some epigrams are harder to swallow in 2026 than they were in 1982. Epigram 71, "Documentation is like term insurance: It satisfies because almost no one who subscribes to it depends on its benefits," still lands. Epigram 27, "Once you understand how to write a program get someone else to write it," is the most concise argument for delegation in management literature.

Epigram 16 remains true: "Every program has (at least) two purposes: the one for which it was written, and another for which it wasn't." This is the origin story of every side-project-turned-product, every internal tool that becomes the most-used thing in a company, and every API that gets discovered and depended upon by people the original authors never imagined.

The Philosophical Core

Epigram 74 is the one that haunts: "Is it possible that software is not like anything else, that it is meant to be discarded: that the whole point is to see it as a soap bubble?" In an industry obsessed with "building for scale" and "long-term architecture," this is a direct challenge to the idea that code should be treated as a permanent artifact.

Perlis saw software as something closer to conversation than construction. You write it, it does something, and eventually it's replaced. The soap bubble metaphor captures something the engineering mindset struggles with: that impermanence might be a feature, not a bug.

Why They Still Matter

The epigrams persist because they describe patterns in human behavior around code, not in the code itself. Languages change. Hardware changes. Methodologies change. But the way programmers relate to complexity, to each other, to documentation, to the languages they love, these remain remarkably stable.

Perlis didn't predict specific technologies. He described the shape of the problems that any technology would eventually face. That's why the collection works as a kind of diagnostic tool: read them against your current project and see which ones make you uncomfortable. Those are probably the ones you should pay attention to.

The full text is short enough to read in an afternoon, and worth revisiting annually. Some things age like milk. These aged like steel.