A 1993 essay argues that Lisp programming works best by extending the language to fit the problem. This bottom-up style produces smaller programs, more reuse, and higher leverage for small teams.
Bottom-up design builds the language up toward the program, not just the program down
In Lisp, language and program evolve together until code fits the problem's natural structure
2 / 15
Top-down design divides a program into nested subroutines until each part is understandable as one unit
3 / 15
Large program components hide errors and make software harder to read, test, and debug
4 / 15
Programmers can add a missing operator, then reuse it to simplify other parts of the program
5 / 15
When the language does more work, less code remains after bookkeeping is abstracted away
6 / 15
Shorter programs need fewer divisions, which makes them easier to read and modify
7 / 15
Bottom-up design makes programs smaller, clearer, and less error-prone by reducing components and connections
8 / 15
Fewer components create fewer connections between components, which lowers the chance of errors
9 / 15
General-purpose operators are easier to read than many special-purpose subroutines
10 / 15
Working bottom-up exposes repeated patterns and can lead to simpler redesigns
11 / 15
Bottom-up design promotes reuse, so a large utility base cuts effort on later programs
12 / 15
Other languages allow bottom-up design through libraries, but Lisp gives much broader power to extend the language
13 / 15
Lisp makes bottom-up design central enough that it becomes a different way of programming