[[91975]]

除非你生活中與世隔絕的深山老林里，否則你應該知道，在眾多的所謂頂級編程高手(alpha geeks)中，函數式編程是十分盛行的。也許你已經使用了某種函數式編程語言。如果你是在使用很傳統的編程語言，例如Java或C#，你應該知道了，這些語言很快就將引入一些函數式編程特征。就在這美麗的新世界即將來到之際，就在我們摩拳擦掌打算大干一番之前，我想，現在應該是我們暫停一下、反省一下函數式編程在我們的日常應用開發中是否合適的好時機。

什么是函數式編程？簡單的回答：一切都是數學函數。函數式編程語言里也可以有對象，但通常這些對象都是恒定不變的——要么是函數參數，要什么是函數返回值。函數式編程語言里沒有for/next循環，因為這些邏輯意味著有狀態的改變。相替代的是，這種循環邏輯在函數式編程語言里是通過遞歸、把函數當成參數傳遞的方式實現的。

為什么要使用函數式編程

擁護者說函數式編程能開發出更高效的軟件，而反對者說反之亦然。我感覺雙方的觀點都有問題。我可以輕松的證明函數式編程能使你更難寫出針對編譯器優化的代碼，或者相較于傳統語言的代碼，JIT編譯器對于函數式代碼會編譯出更慢的程序。命令式編程語言(imperative programming languages)語法跟底層的計算機硬件指令間有著很相似的對應關系，但函數式編程語言卻沒有這種特征。結果就是，編譯器處理函數式編程語言時更費力。

然而，優秀的編譯器能把函數式編程中的閉包、tail調用、或lambda表達式轉換成跟傳統語言中loop循環或其它表達式等效的代碼。這需要多做一些工作。如果你在尋找一本厚達1600頁的關于這方面的好書，我推薦你《Optimizing Compilers for Modern Architectures: A Dependence-based Approach》和《Advanced Compiler Design and Implementation》?；蛘吣阋部梢允褂肎CC或任何具有多階段編譯功能、能生成匯編代碼的編譯器自己去證明這一點。

對于為什么要使用函數式編程，這有一個更好的論據，現代的應用程序都會牽涉到多核計算機上的并行運算功能，程序狀態就成了一個問題。所有的命令式語言，包括面向對象語言，在涉及多線程時，都會遇到共享對象的狀態修改問題。這就是死鎖、堆棧跟蹤、低級處理器緩存命中率低等問題的根源。如果對象沒有狀態，這些問題就不存在了。

在很多地方使用函數式編程或函數式編程語言都是非常適合的，甚至是最好的選擇。對于純函數計算，函數式編程明顯的比命令式編程更合適。但對于商業軟件或其它普通應用軟件，你不能不說這正好要顛倒過來。就像Martin Fowler著名的闡述，“傻子都能寫出計算機可讀懂的代碼。優秀的程序員寫出的是人能讀懂的代碼。”而函數式編程寫出的代碼就是讓人一眼望去不可讀。

幾段代碼就能讓你知道我說的是什么意思。來自Erlang語言的代碼例子：

-module(listsort).  
 
-export([by_length/1]).  
 
by_length(Lists) ->  
 
qsort(Lists, fun(A,B) -> A < B end).  
 
qsort([], _)-> [];  
 
qsort([Pivot|Rest], Smaller) ->  
 
qsort([X || X <- Rest, Smaller(X,Pivot)], Smaller)  
 
++ [Pivot] ++  
 
qsort([Y || Y <- Rest, not(Smaller(Y, Pivot))], Smaller). 

這個是Haskell語言的：

-- file: ch05/Prettify.hs  
 
pretty width x = best 0 [x]  
 
where best col (d:ds) =  
 
case d of  
 
Empty -> best col ds  
 
Char c -> c : best (col + 1) ds  
 
Text s -> s ++ best (col + length s) ds  
 
Line -> '\n' : best 0 ds  
 
a `Concat` b -> best col (a:b:ds)  
 
a `Union` b -> nicest col (best col (a:ds))  
 
(best col (b:ds))  
 
best _ _ = ""  
 
nicest col a b | (width - least) `fits` a = a  
 
| otherwise = b  
 
where least = min width col 

人 vs 機器

一個不怎么樣的程序員一般都能從一段命令式的代碼中很快的看出其基本的功用——甚至這是一種他從未見過的語言。然而雖然你也能從一段函數式代碼里分析出它的功用，但你絕對不可能簡單幾眼就能看出來。不像命令式代碼，函數式代碼并不體現出簡單的語言結構。它展現的都是數學結構。

我們的編程經歷了從紙帶打孔到匯編到宏匯編到C語言(高級宏匯編)再到抽象出了很多老實機器上復制運算的高等編程語言。每一步都使我們越來越接近《星際迷航4》里的場景：遇到麻煩的Scott對他的鼠標說出指令(“Hello computer“)。數十年的進步使得編程語言越來越容易被人類閱讀和理解，函數式編程的語法是在把時鐘指針往后撥。

函數式編程能解決并行運算的狀態問題，但付出的代價是失去人類可讀性。函數式編程也許完全可以用于任何環境開發，它甚至可以通過定義面向領域(domain-specific)的編程語言來拉近人類語言和計算機語言之間的距離。但它糟糕的語法使得它極不適合常規目的的編程開發。

不要這么著急的判斷潮流——特別對于那些不想有太多風險的項目。

英文原文：Functional programming: A step backward

本文鏈接：http://www.aqee.net/functional-programming-a-step-backward/