C++ 會議第一天
Lippman 大牛的第一場，關(guān)于大型可伸縮性的軟件開發(fā)的， Chen Shuo 同學翻譯的很不錯 :D
找到電池，所以可以寫寫了。
果然是牛人啊，上來就講形而上的東西。我聽的有趣，就做了點筆記，但是記的不多。
我們從自然界去尋找靈感，然后在計算機領(lǐng)域去搞出來。以前的計算機是沒有內(nèi)存的，后來馮大俠說，計算機就像大腦，大腦是有記憶的，所以有了內(nèi)存。
我們現(xiàn)在說大腦就像計算機，是本末倒置了。人們總是從自然界的角度來思考，然后解決軟件里的問題。Lippman 牛的想法是，把軟件比作生物，從 DNA ，細胞核開始向上一層層的。
系統(tǒng)的基礎(chǔ)組織部分是 Data Structure 和 Data Stream ，這個就像細胞一樣；在應用領(lǐng)域方面，Executive Function 和 Type Information 就好比生物的各個器官。
大牛參加了許多項目，他抱怨了一輪，說好多都可恥的失敗鳥。大項目就是容易失敗。程序員辛苦啊，根本不是所謂白領(lǐng)。而且每個程序員都是不可替代的。因為每個人的學習經(jīng)歷不同，看待問題不同，寫出來的程序就不同。人們對編程的理解并不像想象的那么美好�，F(xiàn)在慢慢的我們提高了抽象層次，按這個宇宙存在的方式去運作。但是從 java 開始學習編程，對程序員來說是有很大代價的，以前用 pascal 開始學習程序也有很大代價。大約是說，失去了對某些本質(zhì)的理解。形成的對程序世界的世界觀會有問題。
說回大項目，比如他參加的 Visual Studio 就不是啥成功的產(chǎn)品。用 .net 做 Windows 也很失敗，那玩意根本就跑不快。微軟做軟件的哲學有問題，所以做不好。
還有一個土星登陸器的項目，一代代技術(shù)都更新了。他作為技術(shù)顧問，提了些建議。主架構(gòu)師糾結(jié)于用 java 還是用 C++ 這種問題上。其實架構(gòu)師根本不應該關(guān)心用啥語言做。語言好不好都是屁話，把事情做好才對。最終項目是失敗了。有很多問題都不是常規(guī)方法可以處理的。比如通訊的問題，因為土星上有什么什么，導致有時候信號 5,6 小時發(fā)不出去，等等。傳統(tǒng)的通訊連接方式就不適用。
還有好多項目（有具體列舉，沒一一記了），做著做著，做了好幾年，程序員心都涼了。
還有個 MMO 項目，花了幾千萬，但是可恥的失敗鳥。做出來后，什么都好，什么都很完美，只能支持 40-50 人在線。公司還說圣誕就要上。高層說，無所謂，不能玩也無所謂，做出來就好。結(jié)果當然是不能用的。開發(fā)人員心那是拔涼拔涼的。
還有個項目，Sun AT&T 幾個公司想用 C++ 重寫 Unix 。還有 IBM 等等用 Unix 的公司，搞了個啥邪惡同盟。反正最后也是可恥的失敗鳥。
還有 Bell Labs 的 Plan 9 。東西是好的。不過根本不能成為一個產(chǎn)品。這里，提醒各位同學，找工作要小心。先偵察一下，如果公司就是要做個啥項目光沖著賺錢去的，這心態(tài)就有問題，肯定玩完。還有管理人員一定要懂技術(shù)，要知道做的東西是怎么回事。否則碰到這種倒霉事趕緊卷鋪蓋走人，別浪費青春。
又接下去說了好多悲劇，比如 IBM 的 OS/2 啥的。說著說著，說不下去了，名單太長，全是血淚史啊。
Lippman 接著自比江湖百曉生。我覺得他是自謙，想說自己其實只是倚老賣老，知道許多事情，參與了很多項目而已。
正題其實是說怎么做大規(guī)�？缮炜s性的項目。結(jié)論很悲觀，說 C++ 其實不適合做這個。最后我問了個問題，說那什么合適呢。他沒正面回答。不過舉了個例子，提了愛因斯坦的相對論，還有量子力學。大約是想說，C++ 更像是 BS 大牛個人的作品，他一個人構(gòu)架了 C++ 的大部分東西。但是我們未來需要新的語言來解決問題的話，應該參考量子力學的發(fā)展過程，大家一起來構(gòu)架。C++ 呢，說這個最后可能會被我們帶進墳墓。不是 C++ 不好，是因為細節(jié)太多，沒人全搞的明白。結(jié)果每個人寫出來的程序都不一樣。指定規(guī)范很難。最后會有很多人不愿意學。
正題里圍繞的實際例子是在動畫工業(yè)中的。其實做動畫，好多工具都是用完即棄的。提高可復用性，關(guān)鍵在于要把可復用單元做的足夠小。做大就沒人理你了。
他們有人（貌似說的 pixar）做了個神奇的東西，反正就是類似 method 注冊啦，動態(tài)生成類型啦之類的一個奇妙的 C++ 玩具。可以把代碼動態(tài)的以字符串形式注冊進去。動態(tài)生成一些類，一些接口調(diào)用之類。大約加了兩個間接層。代碼里充斥著所謂的注冊代碼。往往多達幾千個。當然性能上也因為這個間接層，下降了幾十倍。
當然，大型可伸縮的項目，性能也不是關(guān)鍵的東西。
這里還插了幾句關(guān)于腳本的。說是有 C++ 程序員說，其實我拿 C++ 寫什么什么也很快的。不過那不行，因為 C++ 程序員太少。你用 C++ 寫沒問題，不過要求你寫完了翻譯成 perl 代碼.
不過這個東西很復雜，所以除了寫它的人，沒人愿意去看怎么實現(xiàn)的。后來做這個的那個家伙回巴黎去了。那些代碼也很可怕，很復雜，里面也有很多 bug 。
后來 Lippman 也做了個類似的東西，也是號稱 Metaprogramming ，不過不是所謂 template metaprogramming ，而是代碼生成代碼。最終自動生成的是 C 結(jié)構(gòu)。不過主要目的達到，就是隱藏眾多細節(jié)。有人說這個不是 OOP ，沒有 class 啥的，不過他認為這個也是 OOP 。OOP 不能看表象。他說，他其實只是想明白個事，關(guān)于靜態(tài)數(shù)據(jù)和動態(tài)部分之類。
這個例子我很有感觸，因為我們公司曾經(jīng)也有個類似的東西。做了個 C++ 和 lua 的巨復雜的粘合層。弄的看起來很高級。結(jié)果發(fā)明和維護的人走了后，用它的項目組都以把這坨東西從項目中去掉為榮。
說起大項目，Lippman 說，一切失敗的大項目都有個通病。就是時間很長，經(jīng)過幾年后，就變成了一個封閉王國。結(jié)果沒人知道在干啥。里面拉幫結(jié)派，為了一些無所謂的技術(shù)問題爭來吵去。其實爭論的都不是要干的事情。
另外，項目太大了后，就沒人了解項目的全部細節(jié)。漸漸的，大家都只關(guān)心自己做的那一塊。這樣很糟糕。他思考后，認為解決的方法是，應該把結(jié)構(gòu)旋轉(zhuǎn) 90 度，變成一個有層次的結(jié)構(gòu)。從上到下一層層剝離。同一層次上就不要橫向切了。
嗯，這個問題我也很有感觸，雖然我的項目不算特別巨大。但是只有我一個人了解項目全部的細節(jié)，這讓人很累。當然如果要每個人都了解全部細節(jié)，就會讓每個人都很累。
以上是我凌亂的一些聽課筆記。很多有趣的東西沒來的及記下。可能也有很多我的誤解在里面。同學們姑且看之吧。
.
