回複幾個問題

這幾天寫了兩篇部落格，很多老朋友關切，問了一些問題。

 

比如說，怎麼又有時間關心技術了？是不是沒那麼忙了？我說，其實一樣的忙，只不過興緻所致，犧牲一些休息時間罷了。說不定一個猛子紮下去，又是長時間潛水。

 

再比如說，怎麼還在搞C++？我說，我沒搞C++，一直以來都是C++在搞我們，我只不過發表一點被搞以後的感想。

 

有人問，你要講的那三個C++特性，網上資料一大堆，你就免了吧。我說，如果我有時間，我會寫的跟網上所有人的寫法都不一樣。比如說，講 function/bind/lambda/closure，我會從 callback 講起，回顧一下 C++中的 virtual function和成員函數指標，MFC中的message mapping，Borland C++Builder中的event handling，WTL的 CRTP 類比虛函數，然後談談為什麼 Java 需要加入 inner class，為什麼C#把 delegate 作為first class citizen，以及 Qt 是如何用 meta-object 系統打造出迄今為止C++最漂亮的GUI架構，以及所有以上一切，在簡單的 C 前是多麼的多餘和廢柴。比如說，如果講 rvalue reference，我會從孤魂野鬼似的匿名臨時對象講起，從 const T&，講到 RVO/NRVO，說不定還會觸及 expression template。

 

但是，我知道我沒那麼多時間來把這些東西都寫下來，寫下來也用處不大。這些東西已經不是今天技術的主流。“why”現在越來越不重要，“how”壓倒一切。

 

“既然如此，你怎麼還在鼓吹C++的那些奇技淫巧？你沒看到C++已經越來越邊緣了嗎？”

 

這個，得容我自辨幾句。

 

首先，我現在只有在業餘時間看看技術，所以當然選自己最熟悉的領域。

 

其次，我不認為C++就沒有用武之地了。C++會長期存在下去，而且在一些特殊的領域裡仍然充當主角。比如，我們不應該小看 Qt 在移動開發中的發展空間，而在一系列我稱之為“對抗性應用”的領域，C++還將佔據優勢，直到出現真正的替代者——肯定不是D，比較有希望的是Go。只是希望Rob Pike老人家堅持到底，不要跟當年plan 9一樣，easy come easy go.

 

第三，最重要的，我鼓吹的不是奇技淫巧。相反，我可能比那些沒學過C++或者被C++難倒的人都更討厭C++中那些奇技淫巧，因為它曾浪費了我大量的時間、精力和熱情。

 

為了講清楚這個問題，我得談談C++的風格，這個老掉牙的話題。

 

上周末跟老朋友聚會，談到技術的時候，有一個共識，軟體開發方面真正有價值的進步，應當是有利於使用者、有利於專案管理、有利於解決領域問題，而不是有利於程式員。多年以來，主流語言和系統的很多改進，其目的都是為了讓寫程式的人感覺更爽，而與使用者、管理和解決問題毫無關係。C++在這方面是帶了一個很壞的頭，又要追求強大的表達能力，又要追求不打折扣的效率，結果搞出一大堆諸如操作符重載，template meta-programming之類的東西。老實講，我也覺得：

 

Matrix4f a, b, c; c = a * (b – a);

 

要比：

 

Matrix4f a, b, c; c = a.mul(b.sub(a));

 

更清爽，但是就算是第二種形式，又能怎麼樣呢？無非多敲幾個字而已，能有多大不了的事？哪個合格的程式員敢說無法理解？可為了讓程式員的視覺更清爽一點，C++花了n年時間，弄出來一大堆奇技淫巧，再與之前之後諸多特性相互幹擾，複雜度成倍增加，

 

有人可能會跳出來反駁說，如果表達能力不重要，那麼你乾脆回去寫彙編好了。

 

所以我得把話說全了。程式的表達能力，只有在反映了其抽象能力的提高時，才是重要的，否則就是自娛自樂。

 

抽象是程式開發的全部意義所在。之所以C比彙編是一個偉大的進步，是因為C建立了一個機器抽象，把諸如寄存器、cache、定址方式、位對齊之類的細節都透明掉了，由此而帶來的表達能力提升，當然是偉大的。但是你看看上面我舉的那個例子，有抽象層次的提升嗎？沒有！有的只是YY暗爽值的提升。這種表達能力提升，如果得來全不費工夫，當然也無傷大雅，如果是嘔心瀝血，傷人一萬，自損三千，竊以為大可不必也。

 

軟體搞了60年，我認為真正被實踐證明了的抽象，一共有四個半，分別是：

 

1. 機器抽象，或者稱語言抽象，構造一台新的電腦或程式語言，使其能理解領域特定的語言，從而最妥帖地解決問題。這是最有力的抽象，是軟體開發中的“火箭科技”。

 

2. 過程抽象，把一件事情看成是一系列嵌套和串接執行的標準化過程的總和，就像流水線一樣。這是極為有力的抽象，因此C語言無所不能。但是層次偏低，規模增大以後帶來一些挑戰。

 

3. 函數抽象，最玄妙的一種，這個我不多說，有興趣的去看 Structure and Interpretation of Computer Programs.

 

4. 物件導向抽象，把一件事情看成是一組各負其責的對象彼此之間相互收發訊息，根據訊息相互協作完成工作的過程。這個抽象也極為有力。

 

4.5 僵化的物件導向抽象，把世界看成是由層次分明、龐雜萬端的類型體系“執行個體化”而出的對象組成的，把事情看成是這些對象之間互相收發訊息、協作而成的過程。

 

問題出在這最後一個抽象上。由於物件導向早期的主要應用場合是 GUI 和模擬，是特別適合於建立類型體系的應用領域，結果人們誤以為這種抽象模型可以應用於所有領域。成長於這個時期的C++受了這種思想的毒害，建立了一個極其嚴苛、吹毛求疵的類型系統，自以為這樣可以在編譯時間發現更多錯誤，沒想到其結果是在編碼時和運行時引起更多麻煩。動態物件導向語言的實踐已經證明，所謂沒有嚴格的類型檢查就無法有效地發現錯誤這一說法，在今天這個時代已經不符合實際了。

 

事實上，後來的實踐表明，拿靜態類型系統去套多姿多彩、變化萬千的現實世界，純粹是人類的狂妄自大。除了在少數幾個完全是人造出來的領域（典型的就是GUI，什麼視窗、控制項、菜單…，完全是人自造的）還是可以的，在很多其他領域則是無力的。所以只能算半個抽象。

 

C++就是被這個半吊子抽象所害，以至今天，積重難返。至於用template泛型去放鬆類型的約束，實屬亡羊補牢。template可謂毀譽參半，其中的精妙之處固然令人激賞，其中詭異無聊之處也令人憤懣。現在boost和其他一些C++庫之中，把template舞得虎虎生風，我也不知道抽象到幾天雲外去了，但是仔細看來，往往是自取其樂，跟實際效果並無干係，反而有礙管理與交流。

 

無論如何，C++已經走到了今天。作為一個提供了較強抽象能力，同時效能又不打折扣的語言，還是不失其地位。

 

以上是個人觀點，僅供參考。