一条长久以来的编程原则讲，程序的基本功能组件不应该太大。如果某些组件的体积膨胀超过了使它们易于理解的程度，它们就会变得像一个藏污纳垢的大城市一样，成为了一个巨大而容易包含错误的复杂体。这样的软件将变得难于阅读，难于测试，难于调试。
经验还告诉我们，一个大程序应该分割成不同的组件来编写。程序越大，它被分出的组件数目也应该越多。那么如何分割？传统的编程方法是使用“自顶向下设计”。例如说：“某程序的设计目标是做这七件事，于是我把它分成了七个主要的子程序。其中第一个子程序是要做这四件事，因此它又被继续分为四个更小的子程序”，等等。这样的分割一直进行到整个程序的分割粒度比较合适为止——每个组件都足够大因而能完成某个实质性任务，同时它也足够小，使得它作为一个独立的单元容易被人理解。
而有经验的Lisp程序员会用不同的方式分割他们的程序。除了自顶向下的设计之外，他们还会遵从一种被称为“自底向上设计”的原则——改写编程语言本身来适应问题的结构。在Lisp中，你不仅仅可以面向编程语言来向下编写出程序，还能逐步构筑自己的语言来向上编写出代码。举个例子，在写代码的过程中你可能会思考说“哦我希望Lisp中有这样或那样的操作符”，此时你就可以径直去实现它。之后你可能就会意识到新添加的操作符也会简化程序其他部分的设计，如此等等。这样的话，编程语言和程序就会共同进化。仿佛是两个交战的国家的边境线一样，语言和程序之间的界限经过程序员的反复重画和界定，最终沿着山川与河流确定下来——那是你要解决的问题本身的天然性质所处的位置。当语言和程序彼此契合之时，你得到的代码就会变得干净，简单和高效。
值得强调的是，自底向上的设计不仅仅意味着换个次序写程序。当采用自底向上方法论时，你通常会得到一份与之前相比大相径庭的程序。取代了之前结构单一，耦合紧密的大块程序，你得到的是一个带有更多抽象操作符的更大的语言集，和一个使用该语言的更小的程序。取代了整块石头构成的门楣，你得到的是由多块石头紧密结合组成的曲形门拱。
采用这样的方法，一旦你抽象出程序中仅仅作为简记的部分，剩下的部分就更小了。你把编程语言的平台构筑的越高，你从顶向下需要前进的距离就越少。这样带来几个好处：
通过让编程语言处理更多的工作，自顶向上设计使得程序更加简短，开发更加敏捷。更短小的程序不需要分割成那么多的组件，而更少的组件意味着程序易读易改。同时，组件之间的耦合减少意味着程序更不容易出错。正如工业设计师努力减少机器中可移动部件的数量一样，有经验的Lisp程序员使用自底向上方法减小代码的长度和错误。
自底向上设计鼓励代码重用。当写两个以上程序的时候，你为第一个程序写的很多工具在接下来的任务中将得到复用。一旦你手里握有足够多作为基础的工具集，写新程序的时候你会发现所需要的劳动比最开始时从一个新Lisp入手所需要的劳动少的多。
自底向上设计使程序更加易读。一个类型抽象的实例就是让读者理解一个普适的操作符，一个函数抽象的实例就是让读者理解一个特殊用途的子程序。
由于自底向上设计方法促使你一直寻找代码中的固定模式，以这种方式工作可以帮助你明晰对要写的程序的设计的想法。如果程序中两个相隔遥远的组件有相同的结构形式，你会注意到其中的相似性，也许能因此简化你的程序设计。
自底向上设计在Lisp以外的程序语言中也可以得到某种程度的实现。库函数就是自底向上思想的体现。然而，在这方面Lisp语言能给你更广泛的支持，增强语言功能是Lisp风格编程非常重要的组成部分——所以Lisp不仅仅是一个不同的语言，它是一种截然不同的编程风格。
一方面，自底向上编程更加适合那些容易分而治之的程序。不过，它同时也增强了程序一个组件的实现能力。在《人月神话》一书中，Frederick Brooks假定一组程序员的生产力并不随着人数增加而线性增长。随着小组人数增加，单个程序员的生产力下降。Lisp的编程经验让我对此有一个更加乐观的表述：随着小组人数减少，单个程序员的生产力提高。一个小组之所以能赢，只是因为它相对来说更小而已。当一个小组能够充分利用Lisp技术的优势，它的胜出将是不可避免的。
