编程极端主义

函数的概念太棒了。为什么我们不编写一个全由函数构成的程序呢？

对象的概念太棒了。为什么我们不编写一个所有东西都是对象的程序呢？

延后执行的概念太棒了。为什么我们不编写一个程序让所有的数据类型都是lazy的呢？

编程极端主义 (跟极限编程没有关系)是一种接受某种理论、在所有事情上检验它、在所有地方运用它的行为。一通实验，尘埃落定后，人们通常会回想这次极端行为，认识到“不错，这很有趣，但很明显，在Y上使用X明显不合适。干这个事情我们需要使用合适的技术！”

这样做的收获：有时候我们应该使用错误的技术干某种工作——因为它有可能是正确的方法，只是你不知道而已。如果你没有尝试过着任何东西都是函数的编程，你可能不会明白函数的功用，例如把函数当作参数，或方便的lambdas。如果你没有尝试过在所有地方都使用对象，你也许就不会明白数字或对象的类都可以是对象。如果你没尝试过着任何地方都使用延后执行，你也许就不会明白纯函数可能是一种更重要的语言特征。

所以会有下面两个建议：

1. 学习一种新理论时，请尝试着在所有地方都使用它。这样一来，你能更快更迅速的知道它适合干什么和不适合干什么，有时甚至你会发现和你最初对它的直觉是错误的。(在这种事情上，这种方法很好，但在另一方面，如果你不知道这种理论方法只适合某些情况，你就错失了更好的认识它的机会)。
2. 如果你想更清楚的了解某种理论方法，使用一种极端的语言或框架系统是最好的方法。如果你想知道延迟执行的程序究竟是什么样的，你就该使用Haskell语言，而不是其它的把延迟执行作为可选行为的语言。虽然这种比较极端的系统的实用性并不是很强，但它们能让你更快的获取学习目标的真谛。

当然，有很多的情况中极端主义是不适合的，但如果是一些有趣的项目，小项目，研究性的项目，这种方法真的可以让你学到很多东西。我的印象最深刻的事情是发生在去年，和Adam Chlipala一起工作。当时我们给Coq做一些校验，我采用常见的方法一步一步的测试，当我大概清楚了整个测试的全貌后，我才开始使用Ltac自动化测试。Adam告诉我：“最初你就应该使用自动化测试，而不是手工的探索。”这一句圣言让我醍醐灌顶：我还不够极端！

文件系统很有趣。为什么我们不开发一个操作系统，让里面的所有东西都是文件形式？

Cons cells太棒了。为什么我不做一个所有东西都是cons cells构成的程序呢？

数学太神奇了。为什么我们不编写一个所有东西都是来自数学的程序呢？

数组太有趣了。为什么我们不编写一个所有东西都是数组的程序呢？