因为Lisp给你自己定义你自己操作符的自由,你可以把它铸造成适合你需求的语言。如果你正在写一个文本编辑器,你可以将Lisp转化成一个写编辑器的语言。如果你正在写一个CAD程序,你可以将Lisp转化成写CAD程序的语言。如果你不知道你在写什么类型的程序,使用Lisp也是安全的尝试。无论你的程序最终会成为什么样子,Lisp将在你写程序的过程中演进到写那种程序的语言。
如果你还不知道你正在写什么类型的程序?他是具有一定模式的:(1) 仔细计划你将要做什么,然后(2)做。根据这个模型,如果Lisp鼓励你在决定它应该怎样工作之前开始写你的程序,那仅仅是鼓励草率的思考。
恩,并不是这样的。计划-实现模式可能对修建大坝或者发动入侵比较有效,但是经验并没有表明这是写程序的好模式。为什么?可能是因为计算机是那么的精确。可能程序之间比大坝或者入侵之间有更多的不同。或者是可能(因为在软件开发的过程中没有冗余旧概念的类似物)旧的方法行不通:如果一个大坝包含30%太过具体,那是错误的边界,但是如果一个程序做30%更多的工作,那就是个错误。
很难说为什么旧的方法失败,但是确实失败了,任何人都能看到。软件什么时候能够按时交付?有经验的程序员知道,不论你怎么样精心计划一个程序,当你真正写程序的时候,你会从许多角度发现计划的各种不足。一些时候计划将是错误的。然而,几乎没有计划-实现的受害者深究基本的问题。取而代之的是,他们责备人的失败:如果计划的制定更有预见性,我们将避免所有的麻烦。既然,即使最优秀的程序员也会在实现时遇到问题,可能期待人们有那么多的先见之明要求有些高了。计划-实现方法可能替换成其它更适合我们限制的方法。
如果我们有正确的工具,我们可以实现不同方式的编程。为什么我们要在实现之前计划?突进一个工程的大威胁是,我们将把我们自己画到角落丽。如果我们有一个更加灵活的语言,这种担心会减少吗?我们做了,并且确实是这样子的。Lisp的灵活性开创了一种崭新的编程方式。在Lisp中,你可以在写程序的过程中做你的计划。
为什么要做事后诸葛亮?正如Montaigne所发现的,没有什么比写更能澄清你的想法。一旦你担心进入死角,你可以利用这点。能够在写程序的时候完成计划有两个重要的结果:可以用更少的时间来写程序,因为,当你同时计划和写程序的时候,你可以聚焦到一个真实的程序上;程序会更好,因为最后的设计总是演进的产品。当寻找你程序的终点的时候,你只要你维护某个训导——只要你随着问题的明朗化,一直尽可能早地重写错误的部分——最后的产品将是一个比你花费几周计划出来的产品更加优雅。
Lisp的灵活性使得这种编程方法成为一个实际的可选项。实际上,Lisp的最大危险是,它可能宠坏你。一旦你使用一段时间的Lisp,你可能会对语言和应用之间的匹配性变得敏感,那样你就不能在回到其它语言后,感觉到它没有给你你需要的灵活性。