Greenspun’s Tenth Rule of programming states: “Any sufficiently complicated C or Fortran program contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.” The line is the work of Philip Greenspun, who states the rule on his own site at philip.greenspun.com. By his own account he wrote it sometime around the early 1990s, possibly for an MIT technical report, and noticed it spreading through Usenet postings before he could pin down exactly where he had first set it down.
The name is itself a joke. It is called the Tenth Rule even though there are no first through ninth rules; Greenspun has explained that there are no preceding laws, only the tenth, and that the number was chosen because it sounded more authoritative than a rule standing alone. This deadpan numbering is part of the humor, in the same tradition as other self-aware programming aphorisms.
The substance of the rule is a pointed observation about language power. Lisp offers features that were exotic when the rule was coined: garbage collection, a read-eval-print loop, macros that let programs rewrite themselves, dynamic typing, and code that is itself a data structure. Greenspun’s claim is that a large enough C or Fortran program inevitably grows its own informal, partial versions of these features, because the problems that demand them do not disappear just because the language lacks them. Configuration systems, interpreters for little domain-specific languages, and plugin mechanisms all tend to reinvent fragments of what Lisp already provides.
Paul Graham, the essayist and Lisp advocate, helped popularize the rule and added a corollary often attributed to him: that any sufficiently complicated such program also contains an implementation of half of Common Lisp that is, by the same logic, the slower and buggier half. Graham used the rule to argue that bottom-up programming and language-level extensibility were undervalued by mainstream practice.
The rule is usually read two ways. Lisp partisans take it as evidence that more powerful languages save you from rebuilding infrastructure by hand. Skeptics read it as a backhanded warning about over-engineering: not every program needs macros and a runtime, and reaching for them prematurely can be its own kind of complexity. Either way, the rule endures because it captures a real pattern: when a language is missing an abstraction the problem genuinely needs, the abstraction gets built anyway, just worse.