惡魔和夢魘的私語------- 關於軟體開發的務虛主義對話(2) (轉)

惡魔和夢魘的私語------- 關於軟體開發的務虛主義對話(2) (轉)[@more@]//////////////////////////////////////////////////////////////////
惡魔吹著笛子來:
這是我對myan的回信（注是〈關於開發的務虛主義對話(1)〉的最後一封信），裡面表達了我對oo和gp的初步的一些想法當然還不是很成熟。

夢魘：
惡魔從軟體開發成本來看待人們對開發語言和工具的選擇與評價，確實是讓我耳目一新，卻又難以完全接受的觀點。
////////////////////////////////////////////////////////
Myan你好：
    很抱歉那麼晚才回復你的來信，這兩封信我等待的很久(有點誇張:) )急切希望得到你對我的GP觀點的看法。因為說道gp我也是門外漢 僅僅是這幾天在csdn上參與你們討論的時候才知道的。說老實話到現在GP的基本沒有寫過，
    STL也僅僅是耳聞但是沒有時間去學習。我僅僅從你們對GP和oo的討論中逐漸摸索出一點粗淺的看法，所以急於想得到你這位GP專家的驗證.當然我也很高興我的看法能夠得到GP圈子的專家的認同。所謂的GP其實也僅僅是我臆造出來的東西，在python中依然以ood/為主導沒有gp這種說法也沒有人這樣做。我僅僅是看了你們對gp的討論以後，聯絡到我正在學習的python突然來了一個靈感：python動態語義的功能或許可以實現 gp。但是我想了兩天但是都是在類似於.utily的繼承兜圈子。後來我看到python
.org上有一片介紹Mixed_in技術的文章。這才讓我豁然開朗只要利用python這種可裝配類的概念肯定可以用python來實現一種別有風味的GP。所以由於python剛學所以編查資料邊程式用一個晚上給你寫了一個bubble sort的sample
    你說你以前是一個語言主義者，很不幸在我大學二年級的時候我曾經也是語言主義者。 甚至可能比你更加低階，認為vc是最好的開發工具對mfc以外的東西都一概排斥。經過半年以後逐漸改變了看法，認為問題不在於那種語言更加先進僅僅是用那種語言實現成本更加低而已。我想成為一個語言主義者是一個程式設計師必然經過的過程。因為初學的程式設計師會投入太多的沉沒成本(sink cost)學習語言的精力和時間的成本無法收回。當然sink cost越高越是能夠阻嚇新競爭者的進入(程式設計師) 。Bjarne不是說過麼"我設計c++語言的目的就是要讓程式設計師有飯吃".當新的技術新的語言出現使得sink cost越來越低，那麼BBS上對程式語言的"文攻武衛"就會越來越多。
    你說GP沒有出路或者說出路目前還不明朗，但是我不 同意這樣的看法。我覺得GP的出路目前 就很明朗。我想沒有必要把所有的東西都變成萬能鑰匙。GP既然在抽象演算法和資料結構上有獨到之處那就應該讓他在設計Comp&Module上發揮應有的功能至於描述世界那是oo的任務我們沒有必要 無限擴充套件他的功能只要夠用就好。我們應該記住，OO的混亂和繁瑣最大的更本原因在於濫用。 用oo去寫Componet就是殺雞用牛刀。
在你另外一封信中談到對目前oo江河日下的問題。我有兩點看法
1．     這裡刪除200字（主要我覺得第一個看法大家並不能夠接受也不一定看的懂）
2. 如果從需求定律的角度來講oo的江河日下未必不是一件好事情。過去十幾年ood/oop的設計開發成本一直下降，那就很容易推測，用oo設計和編寫的程式的平均質量應該下降了。
ood/oop設計開發的成本原來非常高昂，粗製濫造的程式便沒有回報。現在，不管需求大小，oo程式設計設計的成本都非常低，所以越來越多低質的設計和程式得以出現。這並非表示oo的能力下降了，而只是表明設計編寫“較低劣”程式的成本下降了。設計編寫成本下降的本身，使得所有型別的程式都增加了。不過，低質量和高質量程式編寫成本同時下降，會使得低質的設計和程式設計的份額增大，因為現在設計那種程式有了回報。質量更低的東西讓人們多了一些本來沒有的選擇，因為質量更低的東西，其價格也更低。應該說多一些低質量的東西，比
少一些低質量的東西更好。同時，質量更高的東西也更容易得到了，儘管高質量東西比低質 量東西的比例下降了。 今天OO良莠不齊，甚至江河日下的現象，從需求定律的角度來看，倒是一幅令人寬慰的圖景。

另外你提到Ada語言，我以前也有耳聞。今天我到網上找了一下，時間倉促只找到了
sigada83的spec。看了以後我覺得ada的確是一個很優美而且很健壯的語言。但是我發現了
一個問題可能也是Ada不那麼流行的原因，ada不支援型別擴充套件和動態編連（至少我看的ada83版本是這樣不知道ada95有沒有改進).我想ada的失敗的原因大概就是在於此把。好了寫著寫著就發現寫了那麼多東西。希望不要有廢話，也希望sina的穩定一點好讓我快點看到你的來信
祝好
Ian.King

/////////////////////////////////////////////////////////////
惡魔吹著笛子來：
這封信我把話題扯到java的gc上去了。 不過還給他起了一個綽號叫夢魘。是不是很cool呀。
///////////////////////////////////////////////////////////

Hi 夢魘：
sorry你的中文名字在拼音裡面出來了這兩個字。第一我覺得很cool，第二我想不錯惡
魔對夢魘的確滿配(怎麼像是Diablo哈哈:)).
今天我翻了翻你在csdn上的專欄，讀了你幾片文章。覺得你在c++/gp上的確是一個專家。但是當我讀到你討論的java的gc的弱點是隻有程式空閒gc才會回收資源。
第一我不知道sun公司的那些人是怎麼回答這個問題
第二我覺得在jvm的問題上sun公司絕對沒有發言權他們除了誇耀 java在他們昂貴的sun伺服器執行的如何好其他一概不知道。
我做過一段時間的java的performance tuning專門負責Java的Memory Leak(這個leak和你說的問題不同)。這個問題如果是我來回答的話.答案是這樣的1.JVM的GC執行緒可以不中斷程式執行2.Sun的JVM在效能上是比較差的他的回收演算法存在著巨大的問題
第一jvm的gc執行緒的確不需要中斷程式的執行採用-Xingc引數可以把gc的停頓時間減小，如 果你有雙你可以用xingc把gc執行緒掛接到一個空閒cpu上從而使得gc不中斷程式執行。
第二Sun的jvm的效能是很差的，如果你採用ibm的jvm你就會發現他的效能是sun的三倍。而且基於ibm的獨特演算法它的jvm中的gc中斷程式執行得時間比sun短5倍左右特別是在AIX平臺 上ibm的jvm可以做到非同步gc根本就不需要中斷程式執行的功能而sun公司還只是在java1.4.1 的計劃中提到非同步gc功能。
java的gc一方面是解決了大部分memory leak的問題但是更加重要的一方面是防止記憶體的錯誤操作而當機。Java的gc的確不是很成功，因為java的jvm和操作相互獨立導致了效能的緩慢但是那僅僅是一個開端，隨著.net的出現os捆綁Jvm的方案將浮出水面，效能越來越好 的gc將會出現.net的gc比java的更加靈活更加大概速度是java的10-20倍。
當然java不是沒有memory leak，其實memory leak還是存在的而且java的memory leak的出現將比c++的memory leak，更為可怕，更為隱秘，除錯的難度更大。其中 一個典型例子就是在一個生存週期很長中new出的記憶體在這個長週期物件中沒有釋放以前是不會釋放的。
如果要指出java的缺點的話，在我想到可能有以下幾點。
1。能夠快速方便的建立一個應用，但是如果程式有嚴格的效能要求的話那麼花在最後為 這個程式進行的成本將是建立應用的兩-三倍
2。gc機制將導致程式設計師寫出更加不嚴謹的程式碼，使得程式的效能大大降低。根據我的
java的80%的效能問題來源於程式設計師過於依賴gc機制而寫出的低的程式碼因此我的觀點是如果用java書寫依賴於成型的伺服器的(像,,)的話,效能還是能夠接受的。如果用java自己書寫伺服器程式的話需要花費很多時間去做最佳化。
Ian.King

//////////////////////////////////////////////////////////////////////////
惡魔吹著笛子來:
以庫的方式實現gc，我想這是對我認識的一個比較大的轉變。後來仔細審查boost中的share_point和stl的auto_ptr的程式碼感覺到的確這是一個即安全又高效但是又相對簡單的方法。但是我個人比較
偏愛auto_ptr原因是實現比較簡單。

夢魘:
    除了std::auto_ptr之外，boost庫中提供了ped_ptr和shared_ptr。有了這些智慧指標的幫助，我們在程式裡能夠避免絕大多數資源洩漏問題。但是，仍然對於程式設計師提出了很高的要求。
//////////////////////////////////////////////////////////
SnowFalcon兄：
你好！
看了你對Java GC效能的分析，非常欽佩。我對於JVM沒有實質的認識，那篇文章是從網上看到各種爭論後總結而成的，偏重原理分析，而純理論的推論，在實踐資料面前，肯定是蒼白無力的。事實上，有一點可能你不知道，對於資源問題，我一直是贊成GC解決方案的。因為如果GC設計的好，其效能應該超過基於reference counting的smart pointer。但是我的觀點是，GC必須是可控的，召之即來，揮之即去。因此，我贊成以庫，而不是核心語言的機制來呈現GC。目前C++正在著手處理此事，boost.org中已經有個一個標準多執行緒庫。相信在200X版C++中，這個問題會有比較好的解答。
其實我寫這篇文章，倒不是說要打擊Java。只是就事論事。Java如此緩慢，長此以往，是要吃大虧的。宣傳攻勢可以成功一時，卻不能長久。圍繞Java和.NET的泡沫實在太多了，以至於我現在根本不願意去過多的談論他們。還是等泡沫散去，在行評論吧。我並不打算去追逐風潮。事實上，我的觀念裡一直有一種逆反思維，當所有人都衝向一個方向時，真正的機會往往在另一個方向上。所以我跟你談到Ada，這種語言適合於開發極為可靠、高效率和長壽命的大型系統和嵌入式系統。我覺得這恰恰是未來中國軟體市場上一個重要的需求。只可惜現在我沒有精力分心出來系統學習，而且恐怕也很難找到足夠的Ada學友。
  看了你的幾封，的確有很大的啟發。比如你提到Java GC機制對於程式設計師的縱容，談到OO的濫用，確實切中要害。我現在越來越覺得，純技術在實際軟體開發中的作用是有限的，技術人員的素質和團隊的管理，實際上遠比技術重要得多。你從經濟學的角度分析軟體技術發展趨勢的思路，也是非常獨到的。希望更多地聽到你的觀點。這個星期我非常繁忙，到下個星期一，會告一段落。到時候希望能再和你好好談談。我希望能幫助你更多的瞭解目前存在於C++中的GP實現機制，然後由你從自己的獨特視角分析一下這個方向的發展趨勢和前景。

孟巖
10/19


//////////////////////////////////////////////////
惡魔吹著笛子來:
給myan的回信，這封信說的是一些題外話。
/////////////////////////////////////////////////
Hi夢魘:
這個禮拜空下來了吧？看了你上個禮拜的回信感覺比較匆忙，為了便於我們的互相
討論我還想聽聽你對我前幾封信的具體的意見（主要我對GP,OO的發展方向，以及一些
其他的意見比如ood/oop的轉型問題) 同時我希望你能夠介紹一下GP的發展方向和目前的存在的一些問題，以及一些你對GP的內在處理機制的看法。

你說"GC必須是可控的，召之即來，揮之即去”那我想.net中的unsafed程式碼應該能夠滿足這樣的需求。不知道除了這種方式還有其他更好的解決方案。另外最近我也想過，透過追加類似LifeCycle的關鍵字來定義記憶體的生成周期的方式來解決gc的問題，但是這樣和delete的方法沒有任何的區別。

你談到經濟學，經濟學和科學哲學是我目前除了Computer Science 以外最感興趣的兩門學科。對Popper開創的科學哲學對我的方法論有很大的幫助，芝加哥學派的新制度經濟學是我認識世界的認識論的一個標準。經濟學往往被人誤解為模糊的學科，或者是與金錢打交道的學科，但是我的認識中經濟學是解釋人類選擇行為的科學。他不僅僅解釋貨幣，企業的供需問題。更加重要的是他解釋了人類選擇的行為，只要人類那裡有選擇，那裡有能用經濟學來解釋，比如婚姻，忠孝，雷鋒精神和利他主義。我對IT目前的一些看法往往都是從這個方面去考慮的，比如為什麼對於中國大多數企業來說軟體工程是沒有幫助的，為什麼軟體質量的江河日下是一個令人欣慰的圖景，為什麼經濟是在胡說八到，為什麼沒有出路。赫赫當然答案並不是所有人甚至是大多數人能夠接受的。

真想和你能夠面對面的聊聊，的過程太慢，如果你有ociq或者mirc之類的
工具，我想我們的交流可能會更加深刻。
謝謝。
Ian.King