Greenspun's tenth rule

programming

'Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.'

Philip Greenspun's quip (there are no rules one through nine) observes that large programs inevitably grow the dynamic features their language lacks: configuration interpreters, object systems, garbage collection, all reinvented badly. It is the classic argument for choosing expressive tools instead of rebuilding them by accident. The corollary is widely quoted: this includes Common Lisp implementations themselves.

Any sufficiently complicated C or Fortran program contains an ad hoc, informally specified, bug-ridden, slow implementation of half of Common Lisp. Philip Greenspun's rule is a joke with a serious claim: large programs converge on the same set of capabilities regardless of the language they started in.

The observation holds up. Big C codebases grow dynamic dispatch tables, reference counting, a configuration language that acquires conditionals, and eventually something that evaluates expressions at runtime. Each addition is a reasonable local response to a real need, and the aggregate is an interpreter nobody designed, specified or tested as one.

The useful reading is not that everyone should use Lisp. It is that these capabilities are what complex systems require, so the choice is whether to get them from a well-tested implementation or to accrete them accidentally. The accidental version is the one described in the rule: ad hoc because no one designed it, informally specified because it was never written down, and bug-ridden because it was never the thing anyone was building.

← All glossary entries