编程极端主义
函数的概念太棒了。为什么我们不编写一个全由函数构成的程序呢?
对象的概念太棒了。为什么我们不编写一个所有东西都是对象的程序呢?
延后执行的概念太棒了。为什么我们不编写一个程序让所有的数据类型都是lazy的呢?
编程极端主义 (跟极限编程没有关系)是一种接受某种理论、在所有事情上检验它、在所有地方运用它的行为。一通实验,尘埃落定后,人们通常会回想这次极端行为,认识到“不错,这很有趣,但很明显,在Y上使用X明显不合适。干这个事情我们需要使用合适的技术!”
这样做的收获:有时候我们应该使用错误的技术干某种工作——因为它有可能是正确的方法,只是你不知道而已。如果你没有尝试过着任何东西都是函数的编程,你可能不会明白函数的功用,例如把函数当作参数,或方便的lambdas。如果你没有尝试过在所有地方都使用对象,你也许就不会明白数字或对象的类都可以是对象。如果你没尝试过着任何地方都使用延后执行,你也许就不会明白纯函数可能是一种更重要的语言特征。
所以会有下面两个建议:
- 学习一种新理论时,请尝试着在所有地方都使用它。这样一来,你能更快更迅速的知道它适合干什么和不适合干什么,有时甚至你会发现和你最初对它的直觉是错误的。(在这种事情上,这种方法很好,但在另一方面,如果你不知道这种理论方法只适合某些情况,你就错失了更好的认识它的机会)。
- 如果你想更清楚的了解某种理论方法,使用一种极端的语言或框架系统是最好的方法。如果你想知道延迟执行的程序究竟是什么样的,你就该使用Haskell语言,而不是其它的把延迟执行作为可选行为的语言。虽然这种比较极端的系统的实用性并不是很强,但它们能让你更快的获取学习目标的真谛。
当然,有很多的情况中极端主义是不适合的,但如果是一些有趣的项目,小项目,研究性的项目,这种方法真的可以让你学到很多东西。我的印象最深刻的事情是发生在去年,和Adam Chlipala一起工作。当时我们给Coq做一些校验,我采用常见的方法一步一步的测试,当我大概清楚了整个测试的全貌后,我才开始使用Ltac自动化测试。Adam告诉我:“最初你就应该使用自动化测试,而不是手工的探索。”这一句圣言让我醍醐灌顶:我还不够极端!
文件系统很有趣。为什么我们不开发一个操作系统,让里面的所有东西都是文件形式?
Cons cells太棒了。为什么我不做一个所有东西都是cons cells构成的程序呢?
数学太神奇了。为什么我们不编写一个所有东西都是来自数学的程序呢?
数组太有趣了。为什么我们不编写一个所有东西都是数组的程序呢?