程式設計極端主義

　　函式的概念太棒了。為什麼我們不編寫一個全由函式構成的程式呢？

　　物件的概念太棒了。為什麼我們不編寫一個所有東西都是物件的程式呢？

　　延後執行的概念太棒了。為什麼我們不編寫一個程式讓所有的資料型別都是lazy的呢？

　　程式設計極端主義 (跟極限程式設計沒有關係)是一種接受某種理論、在所有事情上檢驗它、在所有地方運用它的行為。一通實驗，塵埃落定後，人們通常會回想這次極端行為，認識到“不錯，這很有趣，但很明顯，在Y上使用X明顯不合適。幹這個事情我們需要使用合適的技術！”

　　這樣做的收穫：有時候我們應該使用錯誤的技術幹某種工作——因為它有可能是正確的方法，只是你不知道而已。如果你沒有嘗試過著任何東西都是函式的程式設計，你可能不會明白函式的功用，例如把函式當作引數，或方便的lambdas。如果你沒有嘗試過在所有地方都使用物件，你也許就不會明白數字或物件的類都可以是物件。如果你沒嘗試過著任何地方都使用延後執行，你也許就不會明白純函式可能是一種更重要的語言特徵。

　　所以會有下面兩個建議：

1. 學習一種新理論時，請嘗試著在所有地方都使用它。這樣一來，你能更快更迅速的知道它適合幹什麼和不適合幹什麼，有時甚至你會發現和你最初對它的直覺是錯誤的。(在這種事情上，這種方法很好，但在另一方面，如果你不知道這種理論方法只適合某些情況，你就錯失了更好的認識它的機會)。
2. 如果你想更清楚的瞭解某種理論方法，使用一種極端的語言或框架系統是最好的方法。如果你想知道延遲執行的程式究竟是什麼樣的，你就該使用Haskell語言，而不是其它的把延遲執行作為可選行為的語言。雖然這種比較極端的系統的實用性並不是很強，但它們能讓你更快的獲取學習目標的真諦。

　　當然，有很多的情況中極端主義是不適合的，但如果是一些有趣的專案，小專案，研究性的專案，這種方法真的可以讓你學到很多東西。我的印象最深刻的事情是發生在去年，和Adam Chlipala一起工作。當時我們給Coq做一些校驗，我採用常見的方法一步一步的測試，當我大概清楚了整個測試的全貌後，我才開始使用Ltac自動化測試。Adam告訴我：“最初你就應該使用自動化測試，而不是手工的探索。”這一句聖言讓我醍醐灌頂：我還不夠極端！

　　檔案系統很有趣。為什麼我們不開發一個作業系統，讓裡面的所有東西都是檔案形式？

　　Cons cells太棒了。為什麼我不做一個所有東西都是cons cells構成的程式呢？

　　數學太神奇了。為什麼我們不編寫一個所有東西都是來自數學的程式呢？

　　陣列太有趣了。為什麼我們不編寫一個所有東西都是陣列的程式呢？

　　原文連結：Extremist Programming