Greenspun's tenth rule

From Wikipedia, the free encyclopedia

Greenspun's tenth rule of programming is an aphorism in computer programming and especially programming language circles that states:[1][2]

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

Overview[]

The rule expresses the opinion that the argued flexibility and extensibility designed into the programming language Lisp includes all functionality that is theoretically needed to write any complex computer program, and that the features required to develop and manage such complexity in other programming languages are equivalent to some subset of the methods used in Lisp.

Other programming languages, while claiming to be simpler, require programmers to reinvent in a haphazard way a significant amount of needed functionality that is present in Lisp as a standard, time-proven base.

It can also be interpreted as a satiric critique of systems that include complex, highly configurable sub-systems.[3] Rather than including a custom interpreter for some domain-specific language, Greenspun's rule suggests using a widely accepted, fully featured language like Lisp.

Paul Graham also highlights the satiric nature of the concept, albeit based on real issues:

That sounds like a joke, but it happens so often to varying degrees in large programming projects that there is a name for the phenomenon, Greenspun’s Tenth Rule.[4]

The rule was written sometime around 1993 by Philip Greenspun. Although it is known as his tenth rule, there are in fact no preceding rules, only the tenth. The reason for this according to Greenspun:

Sorry, Han-Wen, but there aren't 9 preceding laws. I was just trying to give the rule a memorable name.[5]

Hacker Robert Morris later declared a corollary, which clarifies the set of "sufficiently complicated" programs to which the rule applies:

…including Common Lisp.[6]

This corollary jokingly refers to the fact that many Common Lisp implementations (especially those available in the early 1990s) depend upon a low-level core of compiled C, which sidesteps the issue of bootstrapping but may itself be somewhat variable in quality, at least compared to a cleanly self-hosting Common Lisp.[7]

Software engineer then started a proof of Morris' corollary:

I stopped porting Open Inventor to Common Lisp because I was implementing a buggy ad-hoc poorly specified implementation of namespaces in Common Lisp (Scheming Pony's first step in a proof of Morris' Corollary of Greeenspun's 10th) as Open Inventor had done before C++ namespaces were supported, like templates, and multi-methods (still not, I think). Someone also tell Stroustrup to look at Common Lisp macros, and stop the template madness.[8]

This proof jokingly refers to the fact that Common Lisp has a relatively primitive system for partitioning symbols called 'packages' and also that there might be a Greenspun's 11, vis-a-vis C++.

See also[]

References[]

  1. ^ Greenspun, Philip (1990–2017). "Philip Greenspun's Research". Retrieved 2020-12-23.
  2. ^ Graham, Paul (May 2002). "Revenge of the Nerds". Retrieved 2019-10-24.
  3. ^ "Greenspun's Tenth Rule, does every large project include a Lisp interpreter?". Stack Exchange. 2017-04-12. Retrieved 2020-12-23.
  4. ^ Graham, Paul (2004). Hackers & Painters: Big Ideas from the Computer Age. O'Reilly Media. ISBN 978-0-596-00662-4.
  5. ^ Greenspun, Philip (September 27, 2003). "10th rule of programming".
  6. ^ "Lisp Quotes". paulgraham.com.
  7. ^ Rhodes, Christophe (2008-05-15). "SBCL: a Sanely-Bootstrappable Common Lisp" (PDF). Lecture Notes in Computer Science (Self-Sustaining Systems: First Workshop). Retrieved 2020-12-23.
  8. ^ Scheming Pony (2020-02-19). "Vulkanizing". libre-riscv-dev mailing list. Retrieved 2020-12-23.
Retrieved from ""