LISP自底向上设计

    长期以来，我们一直遵循这样一个编程风格方面的原则：一个程序的功能要素不应该太大。如果程序中的某些部件的规模超出了易于理解的范围，就会造成大量的复杂性，这些复杂性很容易隐藏错误，正如在一个大城市中很容易隐藏罪恶一样。这种程序难以理解、难以测试、难以调试。



根据这个原则，一个大型程序必须要分割成一些小块，并且分割的程度应该和程序的规模相称。那么，如何来对程序进行分割呢？传统上，我们一般会使用称为自顶向下的设计方法（top-down design）：程序打算完成7项任务，于是就把它划分成7个主要的子例程。第一个例程要做4件事情，于是就再把它分割成4个子例程。这个过程要持续下去，直到整个程序具有适当的粒度为止。这里适当的含义为：每个部分都大到足以完成一些实质性的工作，并且都小到足以作为一个可理解的单元。



有经验的Lisp程序员却以一种不同的方式来分割他们的程序。和自顶向下设计对应，他们称之为自底向上设计（bottom-up design）：改变语言，使之适合于要解决的问题。在Lisp中，你不是仅仅用语言来编写程序，同时你还要对语言进行增进，使之更加适用于你的程序。在你编写程序时，你会这么想：“我希望Lisp具有某某操作符。”于是你就去把它编写出来。然后，你发现使用这样一个新的操作符会简化程序其他部分的设计。语言和程序在一起演化。就像是位于两个处在战争状态国家的边界一样，语言和程序之间的边界线不断地重新划分，直到最后停留在山川、河流区域――最适合于你的问题的一个自然边界。最后，你的程序看上去就像是使用专门为它设计的语言编写的。当语言和程序相互非常匹配时，代码也会变得更加的清晰、短小、高效。



值得强调的是，自底向上设计并不仅仅是一种以不同的顺序编写同一个程序。当以自底向上方式工作时，通常得到的是一个完全不同的程序。得到的不是一个单片机式的程序，而是一个具有更多抽象操作符的、语义更为丰富的语言，以及一个用该语言编写的更短小的程序。不光得到了结果，你还得到了更强大的表达能力。



我们在编写代码时，一旦剥离出了那些仅仅做一些薄记工作的部分，剩余的核心部分就会变得非常短小，我们把语言的抽象层次提得越高，从顶部到达它得距离就越短。这会带来如下几个好处：



1、              通过使语言做更多的工作，自底向上设计所产生出的程序更加短小、更加敏捷。一个短小的程序就不必再分割成很多的部分，而具有较少的部件则意味着程序将更加地易读和修改。具有较少部分的程序也意味着部件之间具有更少的关联，因此出错的可能性就更少。正如一个工业设计师努力减少机器内部中的运动部件的数量一样，有经验的Lisp程序员也在使用自底向上设计来减少他们程序的规模和复杂性。

2、              自底向上设计鼓励代码重用。当你编写了两个或者更多的程序时，很多你为第一个程序编写的工具也会在后续的程序中发挥作用。一旦你具有了一个大型的工具基础库，编写一个新程序所需要的工作量将会大大低于使用原始Lisp所需要的。

3、              自底向上设计使得程序更加易读。是一个通用目的的操作符好理解呢，还是一个针对特定领域的特定目的操作符好理解呢？

4、              自底向上设计有助于理清自己的设计思路，因为它会迫使你总是去寻找代码中的模式。如果两个不同的部件在形式上非常相似，你就会被引导去注意这些相似性，并且以一种更为简单的方法去重新设计程序。



除了Lisp外，在其他程序语言中也可以在某种程度上实施自底向上设计。只要你看到了库函数，在那里就使用了自底向上设计。然而，Lisp在这方面提供了更为宽广的支持， 使之在以Lisp风格编程方面达到了一种：Lisp不仅仅是一种不同的语言，而是一种完全不同的编程方法的程度。



很显然，这种开发风格更适合于小团队开发。但是，它同时也延伸了一个小团队所能完成的任务的限制。在《人月神话》一书中，Frederick Brooks指出，程序员团队的生产力不会随着团队的规模线性增长。当团队的规模扩大时，个体程序员的生产力会下降。Lisp编程的经验则以一种更为令人振奋的方式表达了这一法则：随着团队规模的缩小，个体程序员的生产力会升高。一个小规模的团队会取得成功，这只是因为它更小一些。当一个小型团队同时也掌控了Lisp所使能的技术时，那么它就会更为彻底地取得胜利。

评论

4 楼 dennis_zane 2008-02-19  

我觉的其实作者这里更多地想表达LISP通过强大的元编程能力去创造出面向特定领域的DSL，通过抽象层次的提升，将大大降低系统的实现复杂度。所谓自底向上应该是这个意思，而不是通常理解意义上的设计范式。

3 楼 greens.leaf 2008-02-19  

自顶向下和自底向上，甚至是两面夹，这种设计/实现方式跟语言选择是没什么关系的东西。

实际上我觉得把这篇文章里的lisp换成c++，c#或者任何一种支持操作符重载的语言，文章本身的立论都“看似成立”。

lisp语言被证明适合在智能搜索的环境下使用，所以一看弄人工自动的博士们基本都用过这个，就跟搞统计的博士们对R或者metalab比较熟是一个道理。

不过lisp用来在程序员之间交换，或者是在Web2.0里面搞定业务层、表示层、ORM，那么恕我驽钝，我觉得你的程序员可以换个公司了。

你提到
    “我希望Lisp具有某某操作符。”于是你就去把它编写出来
我觉得你得考虑到编写出来以后，你得给你的程序员们去做培训，然他们去了解这个操作符的意图和正确的使用方法。假如你的项目里平均每个月会出现一个新的操作符，OK，你应该在每个月开完例会后给你的程序员留点家庭作业。我觉得只有那些非常初级的程序员会接受你这种不停的骚扰，一旦他们不堪忍受他们会非常渴望离开这个lisp团队。

当然，如果你的“小型团队”是指你一个人，或者是你所领导的2～3个人，那这里的大部分观点都是成立的。如果你所需要完成的工作与搜索有特别大的关系的话，那lisp的确是你能找到的最好工具。

2 楼 ShiningRay 2008-02-19  

你得有合格的人来做合适的事情

1 楼 dennis_zane 2008-02-19  

想支持所谓的“自底向上”设计，强大的元编程能力不可或缺