AINEWS
Which of Alan Perlis's 1982 Programming Maxims Actually Held Up?
Alan Perlis, the first recipient of computer science's highest honor, left a list of short programming rules at Yale that engineers have quoted ever since.
Alan Perlis, the first recipient of computer science's highest honor, left a list of short programming rules at Yale that engineers have quoted ever since.
Alan Perlis published a numbered list of short epigrams about programming in 1982, and computer scientists have been quoting them ever since. Perlis, the first recipient of the Turing Award, was not writing satire. He was a founding figure in programming-language design, and his list of programming rules, hosted today on Yale's computer science department site, reads less like a relic than a betting sheet. Each line is a claim about how software should be written. Forty-four years later, with LLM-generated code flooding repositories and microservices fragmenting data models across dozens of services, the claims deserve a verdict: which ones held up, which ones broke, and which ones were always about something other than what they seemed to be about.
Consider the line that has aged most bitterly: "Syntactic sugar causes cancer of the semicolon." Perlis was already complaining in 1982 about syntactic additions that obscure the structure of a program. The complaint has only grown louder. Modern TypeScript decorators, Java's Lombok annotations, Python's dataclass decorators, and the endless stream of language features designed to make code "more readable" have produced codebases where a single line of source expands into a thousand lines of generated behavior. When the generated behavior is wrong, debugging requires reading the expansion. The sugar has not cured the cancer. It has metastasized it.
The LLM moment is a live test of the warning. When a model generates a thousand lines of syntactically correct TypeScript, the question is not whether the code is correct in form, but whether the abstractions are correct in kind. A class decorator that wraps every method in a logger looks like progress. When the decorator hides an exception, the code that uses it stops behaving like the code that was written. Perlis was right: the more sugar between the writer and the program, the harder it is to see what the program actually does.
A second line fares differently: "It is better to have 100 functions operate on one data structure than 10 functions on 10 data structures." The advice, on its face, is a vote for tight, shared data models. The microservices movement of the 2010s ran the other way, splitting data across dozens of services with their own schemas, their own APIs, and their own consistency rules. The promised benefit was independence. The recurring cost has been coordination: transactions that span services, schema migrations that ripple across teams, and the slow discovery that an "API contract" is just a binding pretending to be a service boundary. Perlis's bet, that central data structures concentrate binding and make programs tractable, has been vindicated at the limit. The 100-functions-one-data-structure rule turned out to be about organizational complexity as much as it was about program structure.
A third line, "Every program is a part of some other program and rarely fits," was always going to hold up. It is the kind of epigram that ages by being unfalsifiable: any specific failure of composition is evidence for it. But the broader pattern it names, that software spends most of its life as a component of something larger, has only intensified. Open-source dependencies, vendor SDKs, and internal platform layers mean the average line of code in a production system was written by someone the application team has never met. The 1982 version of this problem was subroutine compatibility. The 2026 version is supply-chain trust, and Perlis's line, read carefully, is not really about subroutine compatibility at all. It is about the asymmetry between the people who write a program and the people who have to live with it.
There is a temptation, reading Perlis in 2026, to declare a winner. The lines about standardization and structural rot have aged well. The lines about parameter counts and recursion are true in a way that was true in 1982 and will be true in 2042. But the deeper lesson is methodological. A programming aphorism is a bet, and bets expire. The ones Perlis got right were the ones that named a mechanism, not a style: complexity grows, binding is expensive, and the cost of irrelevant detail compounds. The ones that have aged worse were the ones that confused mechanism with fashion.
Software engineers in 2026 are not short of maxims. Stack Overflow, conference talks, and LLM code-review tools produce them by the hour. The useful question Perlis's list still answers is not "what should I do" but "what is this rule actually claiming, and what would have to be true for it to stop being true." A rule that survives that question is worth keeping. A rule that doesn't is syntactic sugar of another kind.