What is Greenspun's Tenth Rule?

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

Greenspun's Tenth Rule. According to Greenspun, there are no rules from the first to the ninth; he simply called it the tenth rule because he thought it would be more memorable.

Anyway, this rule is a kind of aphorism(?) related to Lisp, implying that many of the powerful features of Common Lisp inevitably become necessary once a program reaches a certain level of complexity. If you build a complex program using a language like C that lacks such features, you will end up, perhaps unknowingly, implementing similar functionality found in Common Lisp using C. Naturally, these on-the-fly implementations are bound to be inferior in quality compared to the well-designed features of Common Lisp that have been developed and refined over time.

Of course, it is not correct to interpret this rule literally as merely a criticism of C and Fortran. Instead, it should be understood as a humorous expression emphasizing the importance of abstraction and high-level languages in software design.

So, where is the gap?

C and Fortran lack the following high-level features:

• Lack of class and object support: Unlike object-oriented languages, C and Fortran do not have a concept of using classes or objects to abstract data and behavior. To implement such functionality, one has to use a combination of structs and functions to indirectly simulate these features.

• Limitations in functional programming: C and Fortran can use function pointers or procedure pointers to pass functions as arguments, but they do not support advanced function combinations like closures or higher-order functions.

• Memory management: In C, pointers are used to directly manipulate memory addresses. This approach can easily lead to bugs (e.g., memory leaks, pointer errors) when building complex programs. However, in Common Lisp, memory management is handled automatically, so there is no need to manipulate pointers directly.