for 循環為何可恨？

Java的閉包(Closure)特征最近成為了一個熱門話題。一些精英正在起草一份議案，要在Java將來的版本中加入閉包特征。然而，提議中的閉包語法以及語言上的這種擴充受到了眾多Java程序員的猛烈抨擊。

不久前，出版過數十本編程書籍的大作家Elliotte Rusty Harold發表了對Java中閉包的價值的質疑。尤其是他問道“ for 循環為何可恨？”：

如果只說Elliotte質疑不起眼的閉包的價值，這是不公平的。他主要抱怨是，在讀了另一位著名人物、獲得過Jolt 大獎並創造過最高銷售記錄的《Better, Faster, Lighter Java》的作者Bruce Tate的最近的關於此主題的專題後，他看不出閉包在Java中有什麼價值。(Bruce用Ruby做的例證)：

表 1. 最簡單的閉包

3.times {puts "Inside the times method."}  
 
結果：  
Inside the times method.  
Inside the times method.  
Inside the times method. 

times是3這個對象上的一個方法。它把閉包中的代碼執行了3次。{puts "Inside the times method."}是閉包。它是一個匿名函數，把它傳入times方法，打印出靜態句子。相比起傳統的for循環語句，這樣的代碼顯得更緊湊，更簡單，如表2中所示：

表 2: 非閉包的循環

for i in 1..3 
puts "Inside the times method." 
end 

由於這種毫無生氣的對閉包的介紹，我也很難看出它的真正價值。這首個比較，充其量也就能體現出一種微妙的差別。Bruce在developerWorks上的文章裡的其它的例子也大多是價值不大的，要麼含糊不清，要麼缺乏啟發意義。

對於這種Ruby風格的閉包給Elliotte帶來的困惑，我不打算進一步評論；對這種問題過於挑剔毫無意義。我也不想討論目前的關於Java中的閉包的語法的提議的爭論，包括Java中是否應該有閉包這樣的大問題。在這樣的爭論中我沒有立場，說實話，我是不在乎這些問題如何或何時被解決。

雖然如此，Elliotte卻提出了一個重要的問題：for 循環為什麼可恨？

下面是一個常見的例子：

double sum = 0;  
for (int i = 0; i < array.length; i++) {  
sum += array[i];  
} 

這有什麼問題？我編了很多年的程序，我對這種語法一眼掃過去很舒服；很顯然，它是把一個數組裡的值加到一起。但當去真正的閱讀這段代碼時，這四行代碼裡大概散布著30多個標記符號需要我去分析處理。不錯，有些字符可以通過語法簡寫方式來縮減。但為了這樣一個簡單的加法，你需要寫出一堆東西，還要保證寫的正確。

憑什麼這樣說？下面是Elliotte的文章裡另外一個例子，原文拷貝：

String s = "";  
for (int i = 0; i < args.length; i++) {  
s += array[i];  
} 

看見了裡面的錯誤嗎？如果這代碼編譯通過，並通過的代碼審查，你可能需要數周才會發現這樣的bug，再數周才能制作出補丁。這些只是簡單的for循環。想象一下，當for循環體變得越來越大，甚至有嵌套時，事情會變得多麼的復雜。(如果你仍舊不擔心這樣的bug，認為這只是拼寫錯誤，那麼你就想想有多少次在for循環裡你是這樣的。)

如果你能夠把一個簡單的for循環寫成一行，帶有更少的重復和更少的字符，這樣不僅更容易閱讀，也更容易書寫。因為這樣更簡潔，引入bug的機會就更少，當bug出現時，也更容易被發現。

那閉包對此有何幫助？下面是第一個例子，用Haskell語言寫成的：

total = sum array 

哈哈，我是在說謊。sum函數並沒有使用閉包。它是按照fold的方式定義的，而fold是接受閉包的：

total = foldl (+) 0 array 

下面是第二個例子，很常見，而且使用了閉包：

s = concat array  
s = foldr (++) [] array 

我承認，使用這些叫做foldl 和 foldr 樣子古怪的函數來解釋閉包的作用，這對那些更熟悉for循環的程序員來說沒有多大意義。但是，這幾個函數卻能突出for循環的關鍵弊端：它把三種獨立不同的操作合並到一起了——過濾，歸納和轉換。

上面的這兩種for循環，它們的目標是接收一個數值列表，把它們歸納成一個值。函數式編程的程序員稱這些操作為“folds(合並)”。一個fold運算的過程是，首先要有一個操作(一個閉包)和一個種子值，還有使用list裡的第一個元素。這個操作被施加到種子值和list裡的第一個元素上，產生出一個新的種子值。fold運算然後把這個操作運用到新種子值和list裡的下一個元素上，一直這樣，直到最後一個值，最後一次操作的結果成為fold運算的結果。

下面是一個演示：

s = foldl (+) 0 [1, 2, 3]  
= foldl (+) (0 + 1) [2, 3]  
= foldl (+) 1 [2, 3]  
= foldl (+) (1 + 2) [3]  
= foldl (+) 3 [3]  
= foldl (+) (3 + 3) []  
= foldl (+) 6 []  
= 6 

Haskell語言裡提供了很多fold函數；foldl函數從list的第一位開始運算，依次反復到最後一個，而foldr函數，它從list的最後一個函數開始運算，從後往前。還有很多其它相似的函數，但這兩個是最基本的。

當然，folds是一些非常基本的運算，如果拋棄for循環而以各種形式的foldl 和 foldr 咒符來替換，你會很困惑。事實上，更高級的操作，例如sum, prod 和 concat都是以各種folds定義的。當你的代碼以這種高級的歸納操作運算來編寫時，代碼會變得更簡潔，更易讀，更易寫，更易懂。

當然，並不是所有的for循環都是歸納操作。看看下面這個：

for (int i = 0; i < array.length; i++) {  
array[i] *= 2;  
} 

這是一個轉換操作，函數式編程的程序員稱之為map操作：

new_array = map (*2) array 

map函數的工作方式是，它會檢查list裡的每個元素，將一個函數應用到每個元素上，形成一個新的list，裡面是新的元素。（有些語言裡的這種操作是原位替換）。這是一個很容易理解的操作。sort函數的功能相似，它接受一個list，返回(或修改)一個list。

第三種類型的for循環是過濾。下面是個例子。

int tmp[] = new int[nums.length];  
int j = 0;  
for (int i = 0; i < nums.length; i++) {  
if ((nums[i] % 2) == 1) {  
tmp[j] = nums[i];  
j++;  
}  
} 

這是一個非常簡單的操作，但使用了for循環和兩個獨立的計數器後，毫無必要的復雜表現把事實真相完全掩蓋了。如果過濾是一種基本的操作，它應該像一個fold或一個map那樣，而事實上，它是的：

odds = filter (\i => (i `mod` 2) == 1) nums  
odds = filter isOdd nums -- 更常用的形式 

從核心上講，這就是為什麼for循環有問題：它把(至少)三種獨立的操作合並到了一起，但重點卻關注了一個次要細節問題：遍歷一系列的值。而事實上，fold，map 和 filter是處理一個數據list的三種不同的操作，它們應該被分別處理。采用把閉包傳入循環內的方式，我們能更容易的把what 從 how 中分離出來。每次遍歷一個list時我都會使用一個匿名函數，或復用通用的函數(例如 isOdd, (+) 或 sqrt)。

雖然閉包並不是一個很深奧的概念，但當它深深的烙進了一種語言和它的標准庫中時，我們不需要使用這些低級的操作搞的代碼混亂不堪。相反，我們可以創建更高級的運算，做我們想要的事，比如sum and prod。

更重要的，以這些概念思考問題會使我們更容易思考更復雜的操作，比如變換一個tree，過濾一個vector，或把一個list合並成一個hash。

在最後，Elliotte還提到了一些關於在多核處理器上並行執行的問題，說像3.times {...}這樣的代碼會比 for 循環效率“差”。不幸的是，我想他沒說到點上。不錯，有一些運算需要序列化，有一些可以並行。但是如果你只基於一個for循環，很難判斷出哪些歸為哪類，這是一個復雜的編譯器優化問題。如果你把一個可能進行並行運算的操作(例如map 和 filter)分解成連續的運算(例如foldl 和 foldr)，編譯器更容易從中做出判斷。不僅如此，如果你比編譯器更了解你的數據，你可以顯式的要求一個map操作被順序執行或並行執行。