原文：http://jjhou.boolan.com/programmer-5-talk.htm 侯捷老师官方网站：http://jjhou.boolan.com/ 感谢严冬师兄给我推荐这篇文章！ -------------------------------------------------------------------------------- 侯捷觀點漫談 程序員與編程 random talk on programmer and programming 北京《程序員》2001.05 台北《 Run!PC》2001.06 作者簡介：侯捷，*電腦技術作家，著譯評兼擅。常著文章自娛，頗示己志。個人網站：www.jjhou.com 北京鏡站：www.csdn.net/expert/jjhou -------------------------------------------------------------------------------- 「侯捷觀點」進行了4期。通過這個專欄的作用，我開始接觸大陸的電腦技術刊物《程序員》和電腦技術網站 CSDN，並累積了相當量的觀察和感想。這個專欄前數期談的都是技術，不是深度書評就是高階技法。這一期讓我們輕鬆一下，談談程序員（programmer）與編程（programming）。其中不少議題起因於讀者來信的觸發，許多觀點我也已經回應於侯捷網站上。所以若干文字可能你曾經在侯捷網站上閱讀過。有些看法也許讀來刺眼，聽來刺耳。但如果大家不把我視為外人，當能平心靜氣地思考。*存在許多相同的問題，我也時常為文針砭。 有一句話這麼說：如果你想使人發怒，就說謊。如果你想使人大怒，就說實話。說實話的人來了，但願你心平氣和。 急功近利是大忌一位讀者寫信給我，說他非常著急。他一個月掙300元人民幣，家裡情況又不好。他希望趕快把 VC/MFC 學會，進入 IT 產業掙錢。信寫得很長，看著看著，我也不禁為他著急起來。 有許多讀者，雖然情況沒有那麼急迫，燃眉之情卻也溢於言表。不外乎都是希望能夠儘快把某技術某技術學習起來。 但是哪一樣東西哪一樣技術是可以快速學成的呢？能夠快速學成的技術，人才也就必然易取易得，根據市場供需法則，也就不可能有很好的報酬。所以諸君當有心理準備，門檻高的，學習代價高，報酬高；門檻低的，學習代價低，報酬低。 說起來是老生常談了。這其中最可怕的心理在急功近利。從讀者的來信，以及從 CSDN 上的眾多帖文，我感覺，許許多多人學習 IT 技術，進入 IT 產業，是認為 IT 產業可以助你脫困，遠離貧窮。 是的，IT 產業有這個「錢」景，但你得有那份實力。要吃硬核桃，也得先估量自己的牙口。 「好利」是基本人性，Acer 總裁施振榮先生大力提倡「好逸惡勞」之說，視為人性之本，進步的原動力。誰能說不是呢？好利可以，近利就不妙了。近利代表目光淺短，一切作為都因此只在小格局中打轉。 梨園有句話：要在人前顯貴，就要在人後受罪。台上一分鐘，台下十年功。老祖宗這方面的教誨太多了，身為中國人的我們，應該都耳熟能詳。 對於心急的朋友，我只有一句話：勿在浮沙築高台。你明明很清楚這個道理，為什麼臨到自己身上，就糊塗了？急是沒有用的，浮躁更會壞事。耐住性子紮根基吧。做任何事都要投資，紮根基就是你對自己的未來的投資。如果想知道如何按部就班紮根基，侯捷網站上有一篇文章：「97/06 選義按部 考辭就班」，請你看看。 口舌之戰有何益最常在程序技術相關論壇上看到毫無價值而又總是人聲鼎沸的口舌之戰，就是諸如「VB 和 Delphi 誰好」、「BCB 和 VC 誰優」、「Linus 和 Windows 誰棒」、「Java 和 C++ 誰強」這種題目。每次出場都一片洋洋灑灑，紅紅火火急速竄升為超酷話題。眾人各擁所好，口沫飛揚，但是從來說服不了任何異陣營的人，話都只說給自己人聽，給自己人爽。 這樣的論戰有何意義？許多人在重組自己的偏見時，還以為自己在思考呢。戰到最後，就只是爭誰說最後一句話而已。而且，擦傷引起的爭吵幾乎總是以刺傷結束。 工具與技術的評比，是一場高水準的演出。真有能力做評比，侯捷是很尊敬的。但是這些各擁所好，口沫飛揚的人，真的對評比兩造都有深刻的了解嗎？很多時候我們看到的只是無知，而無知是這麼一種東西 : 當你擁有了它，你就擁有巨大的膽量。 很多人喜歡某種工具，只不過因為那是他的初體驗。他玩它玩出了一點心得，可以說出它的某些好，就開始做「評比」了。你只看到牡丹的豔麗，又怎知寒梅的清香，幽蘭的空靈？ 絕大多數人使用某種工具，不是因為它最好，不是因為眾裡尋它千百度，僅僅只是因緣際會。雖然說不同的應用環境選擇不同的工具，是最伶俐的作為，但我真的懷疑，在現今工具（以及工具背後反映的技術）如此繁複的時空下，有多少人能夠同時精通一個以上的同質工具？追二兔不得一兔，我還是認為你精專一樣工具，把它發揮到最高效能，獲得的利益多些。被大家拿來評比的，都是市場上的佼佼者，還能差到哪裡去？能夠兩雄相爭，必然是在技術面、非技術面（資源的普及、品牌的可靠度）各有一片天，你的評比意義大嗎？全面嗎？ 大多數人沒有能力同時精通兩種同質工具，初學者聽了網路上不知名大俠的高論，也不可能有所選擇（如果有，怕也只是矇著頭瞎選）。這種沒有提供數據，評論者也沒有顯示任何信譽（credit）的論戰，沒有任何意義，純粹只為自己爽。浪費網路資源！ C++ 之父 Bjarne Stroustrup 曾經在他自己的網頁上的 FAQ （以及其他許多場合）中回答如下問題。雖然其中談的是語言，但是擴大到其他層面仍然合適，值得大家好好咀嚼（註：全文由孟岩先生譯出，可自侯捷網站瀏覽）： Q: 你願不願意將C++與別的語言比較﹖ A: 抱歉，我不願意。你可以在The Design and Evolution of C++的介紹性文字裡找到原因。有不少人邀請我把C++與其它語言相比，我已經決定不做這類事情。在此我想重申一個很久以來我一直強調的觀點：語言之間的比較沒什麼意義，更不公平。主流語言之間的合理比較要耗費很大的精力，多數人不會願意付出這麼大的代價。另外還需要在廣泛的應用領域有充份經驗，保持一種不偏不倚客觀獨立的立場，有 公正無私的信念。... 人們試圖把各種語言拿來比較長短，有些現像我已經一次又一次地注意到，坦率地說我感到擔憂。作者們盡力表現出公正無私，但最終都是無可救藥地偏向于某一種特定的應用程序，某一種特定的編程風格，或者某一種特定的程序員文化。更糟的是，當某一種語言明顯地比另一種語言更出名時，一些不易察覺的偷梁換柱就開始了：比較有名的語言中的缺陷被有意淡化，而且被拐彎抹角地加以掩飾；同樣的缺陷在不那麼出名的語言裡就被描述為致命傷。同樣的道理，較出名的語言的技術資料經常更新，而不太出名的語言的技術資料往往是陳年老酒，試問這種比較有何公正性和意義可言？ Q: 別人可是經常拿他們的語言與C++比來比去﹐這讓你感到不自在嗎﹖ A: 當這些評比不夠完整，或者出於商業目的，我確實感覺不爽。那些散佈最廣的比較性評論大多是由某種語言，比方說Z語言的*者發表的，其目的是為了證明Z比其它語言好。由於C++被廣泛運用，所以C++通常成了黑名單上的頭一個名字。通常這類文章被夾在Z語言供貨商提供的產品之中，成了其市場競爭的一個手段。令人震驚的是﹐相當多的此類評論竟然引用的是那些Z語言開發廠商的員工的文章，而這些經不起考驗的文章無非想證明Z是最好的。尤其當評論之中確實有一些零零散散的事實...，特意選擇出來的事實雖然好像正確，有時卻是完全誤導。 以後再看到語言評比文章時，請留心是誰寫的，他的表述是不是以事實為依據，以公正為準繩，特別是評判的標準是不是對於所引述的每一種語言來說都公平合理。這可不容易做到。 我說過了，真正精譬的技術評比，對於相當程度的研究者，是很有價值的，但我很少在論壇上看到精品 — 論壇還能有什麼精品，99% 是打屁閒談沒有營養的文字。我們每每在其中看到偏見、我執、以及最後免不了因擦傷而引起的刺傷。這真令人傷感。這些人把時間拿來學習，多好。奉勸各位少花時間瞎打屁，多花時間學習，看些真正的精典，別動不動就在論壇上提問，也別動不動就掛在論壇上看別人的瞎打屁。 不但評比性的話題，大家喜歡強出頭，其他話題，情緒性的反應也很多。中國強盛之道，眼前彷彿全壓寶在 IT產業（尤其軟件工業）上面。程序員被賦予了過多的期許，程序員也自我膨脹了許多。夾雜著民族主義或個人好惡，看到不滿意的人事物，就號召大家「黑（hack）」過去。這是什麼心態？比拳頭嗎？說實話，就算要比拳頭大小，「黑」個網站算是什麼尺寸的拳頭？網路是個大暗室，君子不欺暗室。 雜誌定位在哪裡 CSDN上頭，前一陣子曾經請大家就《程序員》的定位問題給意見。很熱鬧。我不知道刊物掌門人在看了那麼多建言之後，有沒有收穫。猜想是沒有 — 就算有也恐怕不大。 就像面對書籍一樣，讀者最直觀的感覺，就是要看他所需要的東西。100個人有100種需求，這樣的詢問得不出總結。隱性讀者、不上網的讀者、不投票的讀者、不寫帖文的讀者，你又如何知道他的想法。 我以為，只需把握一個原則：永遠比大眾水平高一個檔次，扮演引導者，帶領讀者接觸前沿思想與宏觀視野，那就是了。讀者本身會成長，不論你把刊物定位在實質技術的哪一個層次，都會有人不滿足；今年的讀者成長了，不見得明年還是你的讀者。唯有保持前沿思想與宏觀視野，時常導入新的技術形式、新的思維、專家的見解、意見領袖的看法，才能夠長期吸引讀者，並對許多人以及整個技術開發環境做出長久的貢獻。 美國大物理學家費曼，曾經批評物理課的教學。他說老師老是在傳授解物理習題的技巧，而不是從物理的精神層面來啟發學生。這一點是不是可以給刊物經營者和刊物讀者一點點啟發？ 以此觀之，就我個人的專長領域，STL 之父訪談錄、算法大師 Donald Knuth 採訪、C++/OOP 大系、GP/STL 大系、將標準C++視為一個新語言…以及一些總括性、大局觀的文章，是我認為最好的主題。此中有侯捷自己的作品，唔，我向來不客氣。 當然啦，太形而上的東西是不行的，太過抽象的東西不容易被接受。抽象層次愈高，人的*度愈大，但抽象思考是層次高的人的專利，要普羅大眾能夠接受，還需具象細節稍做輔助。 如何長期保持具有前沿思想與宏觀視野的稿源？與外國雜誌合作是一個既快又好的辦法。每一期《程序員》最前數頁都有當期重要外文期刊的前沿摘要，可見《程序員》編輯群一直與外文專業期刊保持著閱讀上的接觸。要挑選合作夥伴，心中一定有譜。 當然啦，與國外合作涉及經費問題。旁人（尤其讀者）很難體會或換位思考經費上的種種困難。就像有人痛心疾首義正詞嚴地埋怨 CSDN 速度慢得像蝸牛，卻可曾想過網站的資源從哪裡來。向你收費，你接受嗎？*已經倒掉很多很多家著名的網站，我等著看免費的服務撐到幾時。 要刊物宏觀耐讀，讀者們也得成熟些。一群很好的讀者，才拱得起一本很好的刊物。 下面是一封讀者來信：現在技術發展太快了，國外（甚至印度）在實現「軟件工業化」的時候，大陸（至少我周圍是這樣）還停留在小作坊手工打造的水平。我認為未來的世界不再屬于「個人數字英雄」，軟件工程似乎比一兩項技術更迫切。以您的大局觀和丰富的閱歷，對這個問題是否有不同的看法，不知您是否愿意就此從技術（或其他）角度寫篇文章發表您的見解。 軟件工程對整個軟件工業的提昇，至為重要。但是一個程序員要修練到對「軟件工程」這個題目感興趣，非三五載（甚至更多）不為功。我的意思是什麼呢？我的意思是，這類書籍、這類工具、這類網站、這類刊物，在一個嘈嘈切切、急功近利的環境中難有生存空間。這是為什麼蔣濤先生想要將《程序員》雜誌導向軟件工程主題時，我對他興起巨大的尊敬與憂慮的原因。 順帶一提，《程序員》的文字水平一直以來帶給我「閱讀的樂趣」。這個評語我從來少有機會用在*的電腦刊物或電腦書籍上。比起*的電腦讀物，這裡的文字有深度多了。 輕浮躁進沒信心只要上網看看程序員出沒的論壇，你就會看到一片浮躁與焦慮。反映出來的就是沒有信心。 「C# 推出，Java 將死」，「Java 演進，C++ 將亡」，「.Net 推出，VB程序員死定了」，「Kylix 推出，大夥兒快學」，「Delphi 持續新版，哥兒們別怕」，「我剛學VC，怎麼它就出場了」，「MFC 真的要過時了嗎」…。諸如此類的問題，不知該歸類為謠言還是童語？ 很奇怪也很感嘆，為什麼大家對這類問題如此感到興趣。那透露出一種膚淺 — 沒有深刻瞭解技術本質，因而汲汲營營慌慌張張惶惶惑惑於新工具、新事務、並且認為新的大概一定都是好的。對自己沒有信心，對整個環境也沒有信心。 有深度的程序員絕對不會在意這種事情。當然，並不是早晚三柱香就萬事保平安。並不是告訴自己別在乎別在意，就真的能夠不在乎不在意了。那必需是發自內心，胸中自有丘壑的一種篤定，有著好的本質學能做靠山。 * BBS（連線）前陣子也有許多熱烈討論 Java, C#, C++, .NET 的貼信。我把我最欣賞的一封引於下。其最後結語，擴張到任何領域都是合適的。 發信人: algent@kkcity.com.tw (流雲), 看板: programming 標 題: 一些想法Re: 不懂,業界一直喊Java,在喊些什麼..." 發信站: KKCITY (Sun Feb 18 12:55:49 2001) 以目前台灣業界的情形來看，C/C++ 應該是想成為一個軟體工程師的基本技能；至於 Java，如果熟悉 C++，學 Java 應該花不了一個月的時間。 以我個人的觀點，Java 的 OO 程度是勝於 C++ 的，而且在這個 Internet盛行的年代，效率的瓶頸在於網路本身的頻寬而不在單機執行時的效率，Java 所提供的 Collection framework 是非常威力強大的程式設計工具，又內建了對 Multi-thread 程式的支援，豐富的 class library 讓人在設計網路、資料庫…的相關軟體時無後顧之憂。 C++ 可能是過去十多年以來最重要的程式語言之一，它的效率顯然較Java為佳，但在撰寫需要安裝在Internet上成千上萬種不同廠牌的機器上執行的程式時，相對於Java可能就不是最好的解決方案。 「目前」不需要以 Java 來開發 DeskTop 上的應用程式，因為「當下」而言 Java 撰寫的程式相對於 C++ 會佔據更多的記憶體且執行效能不彰。 我們不能期待免子游得比魚快，也不能期待魚飛得比鷹高。 工程上的需求使得各種場合有不同的適合的程式語言，不必費心去批評 A、推崇B、打壓 C。基本的理論比這些事重要多了。 VB 將死？Java 將亡？C++ 將被 Java 取代...，這很重要嗎？我用Java 也用 C++，即使明年它們全都被 Java++、C++++、Lisp++、Forth++取代，何有於我哉？FFT 還是 FFT、Dijkstra algorithm 還是Dijkstra algorithm...還是別太擔心這些事了... 侯捷除了偶在 BBS 上自說自話外，絕少回應或參與討論。看了上封信，忍不住回了一帖： 作者: jjhou (jjhou) 看板: programming 標題: 一些想法Re: 不懂,業界一直喊Java,在喊些什麼..." 時間: Fri Feb 23 21:12:14 2001 同意你的看法。寫得非常精采。 人到了一個層次，才會去思考事物的本質是什麼，不被浮面的工具所繫絆。 熟練工具是必要的，但工具的演化汰換，不是大家在這裡關起門來喊爽就好。 Donald Knuth 說：「語言持續演進，那是必要的。不論現在流行什麼語言，你都可以肯定十年二十年之後它不再風光。我總是在自己的書中寫些不時髦的東西，但這些東西卻值得後代子孫記取。」（註：以上局部是《程序員》2000/12 的譯文） DDJ 1996/04 p18: "Language keep evolving, and that is necessary. ...Whatever computer language is in fashion, you can guarantee that whitin a decade or two it will be completely out of fashion. In my book, I try to write things that are not trendy, but are things that are going to be worth remembering for other generations." 追求新知固然是一個計算機從業人員該有的態度，但是追求新工具與充實固有知識兩者之間，應該取得一個平衡。過猶不及！ 再說，凡走過必留下足跡。你現今的任何努力，只要它是紮紮實實的，就絕不至於落空。技術是有累積性的呀，技術總是觸類旁通的呀。你說 MFC 和 OWL 就沒有累積性，我說有，message map 的原理不一樣嗎？framework 的工作原理不一樣嗎？ 我個人並非任何語言或任何工具或任何技術的狂熱者，我是務實派。對於自稱熟稔多種（屬性不同的）語言的人，我充滿敬畏並保持工作上的距離。要精通一個語言，使自己能發揮其最大效能，不是件容易的事，需要不少精力的投注。99.99% 的人都是凡人，身為凡人的我們，把時間用來精通一（或二）種適合其工作性質的「語言」，比泛泛認識多種「語法」，要高明得多，回報也大得多。 真的，還是別太擔心誰將興起誰將亡的事了吧。 天才的沃土教育永遠是我最關心的議題。教育的重要性絕對不亞於產業。沒有好的教育，何來好的產業人才？ 學校教育就不提了，那不是侯捷能夠著力的地方。雖然我也在大學教書，但一年不過教育數十位學生，影響能有多大？書籍的讀者動輒數萬人，刊物的讀者動輒數十萬人，這才是有大影響力的地方。 自修教育如影隨形，打你離開學校就跟隨你一輩子，重要性遠勝於學校教育。談到自修，離不開讀物 — 各種型式的書籍和刊物。在咱們程序員這一行，書籍和刊物的情況如何？ 下面是一封讀者來信：我記得您說過，到一個地區的書店去逛逛，對這裡的IT技術水平就知道大概。這話太得我心了。我學習軟件技術5年，花在買書的錢有一萬二千（人民幣）以上，如今回頭來看，絕大部份是垃圾。以前曾經擔心：若要到外地工作，這麼多書怎麼帶走﹖現在則是一種心痛的輕鬆，因為值得帶走的書只夠一提。學習IT之初，誰不想在產業上做出一番成成績？但多年之後回首，則恐怕都會為自己當時所處的教育環境痛心。 關於計算機書籍的浮濫、低劣，我收到太多太多的讀者反應了。以上只是冰山一角，有興趣的讀者請上侯捷網站看個飽。有些出版社甚至以出爛書聞名，看看這封信： 您想必看過蔣先生在《程序員》上寫的文章﹐知道所謂IT出版四大家。蔣先生可能礙於禮儀，有些地方還沒講透。例如其中的XXX出版社，在譯作方面現在已經是一塊榜樣 ─ 粗製濫造的榜樣。 再看這封信： 我在您網站中看到了有關對關於xxx 出版社的評價，深有感慨。其實該出版社是大陸IT業引進外文書籍的鼻祖，我們這一輩程序員(92年以前的)就是讀該出版社的譯著成長起來的（我至少還有兩大紙箱xxx出版社的舊書），在那個時候，差不多所有的計算機類圖書都是它們引進並翻譯的，現在看來，那個時候的翻譯質量差得無法忍受（比Incide VC++ 5/e還差許多），但我們那個時候已經很滿足了，畢竟有比沒有好。現在大家對xxx出版社的批評，我想是競爭的結果，因為大家看到了更好的譯著，有了比較。總而言之，xxx 出版社當年的特點是大量翻譯，草草出版，讓科技人員能夠在儘快的讀到優秀作品。這種作風顯然已經不合時宜了，或者說它已經完成了它的歷史使命。我現在當然也不象從前那樣狂買xxx 出版社的書了，因為有了更多的選擇。 這封信讓我跌入回憶。*也曾有兩家出版社，有過同等劣質的作法。這兩家惡貫滿盈的出版社，一名瑩圃，一叫松格。兩家都關門了。他們的作法都是，快速而大量地翻譯外文書。由於速度快，也由於選材之中不乏好書，所以曾經擁有一定的市場。怎地都關門了？因為讀者只能被欺負一次兩次，不會永遠當傻瓜。這樣的出版心態擺明沒有長遠打算，只想撈一票走人，不關門才怪。 我們可能因為，垃圾堆中多少撿過一些經過修補尚稱堪用的東西，而對刻意製造這些垃圾的人產生一種奇怪的情愫。東西明明不好，但我們從中吸收了一點點養份。該謝他還是該恨他？ 該唾棄他！ 這些商人之所以大量而快速地引進外文書，因為有利可圖。有利可圖是好事，但他沒把他該做的事做好。他們放棄品質而無所懼，因為他們知道，在怎樣的時空背景下可以怎樣輕鬆地賺錢。大陸出版界朋友告訴我，誰誰誰（都有名有姓）很輕鬆地在幾年裡就這樣積聚了幾百萬人民幣的身家。幾百萬人民幣呀，我的天。這也算 IT 產業吧，果然是一片紅火，雞犬昇天。 因努力做事而致富，應該得到我們的讚美和祝福。可這樣的出版社，花更大的功夫賺更多更長遠的錢他們不要，因為輕鬆錢賺起來不費勁兒。百分之一的人可能從這些垃圾中吸收到一些養份，百分之百的人從中感受了閱讀的痛苦。誰知道從中被誤導的人又有百分之幾？買書的錢我們沒少花，得到的正價值卻是那麼少，痛苦指數那麼高。 這位讀者說『總而言之xxx 出版社當年的特點是大量翻譯，草草出版，讓科技人員能夠儘快的讀到優秀作品』，又說『它們引進並翻譯的，現在看來，翻譯質量差得無法忍受』。喔，一本優秀的原作，經過無法忍受的翻譯質量洗禮後，還會是一本優秀的作品嗎？待人寬厚是美德，但是刻意製造餿水油讓人吃壞肚子者，不值得為他們說話。你說『它已經完成了它的歷史使命』。不，他們從來就沒有歷史使命，也沒有使命。 如此「仁厚自持」而且忍耐度奇佳的讀者，相當稀少。絕大部份程序員談到計算機圖書，都是斑斑血淚的控訴。《程序員》2001/03 p119 可不就有一篇「計算機圖書出版商的陷阱」。 讀者來信寫道： 魯迅說，未有天才之前，應該要先營造天才的土壤。...您的心情我確實能夠深刻理解（這大概就是堆在牆角那幾百本垃圾書的最大貢獻吧）。 「天才的土壤」，嗯，魯迅說得好。不正應該是出版社的職志嗎？我們卻能向誰說去？其實我們也只是希望有一些好書造就一些資質不錯的程序員而已。前一陣子才沸沸揚揚於印度程序員與中國程序員的比較，我們哪企望天才？不過就是希望培養一些紮實的人才而已。 看倌也許奇怪，書不好，侯捷為什麼不把矛頭對準作者，卻大罵出版社。哇勒，我早就抱著「得之我幸，不得我命」的卑微態度，不敢期望創作性中文好書。上面我說的，以及讀者最痛心疾首的，是翻譯書的低劣水平。人才濟濟的中國，怎麼可能找不到夠格的譯者？如果不是出版社的搶錢搶短心態，會造就出這一大批劣品嗎？我能不怪罪出版社嗎？ 到頭來，還是要靠自己。「計算機圖書出版商的陷阱」一文最終是這麼說的：『記住，您花的是自己辛苦掙來的錢，所以千萬不要浪費在沒有用的東西上。對於出版了優秀圖書的出版公司要有所回報。買他們的書，給他們寫信，讓他們知道你在想什麼，你需要什麼。』 良性循環一個體系的建制，需要從底層到頂層的堅實構築。不論是 C++, Java, .Net, OO, UML, Windows programming, Linux programming，每一個主題欲成就一個完整體系，都需要一大套書。拿C++/OOP 來說，就得涵蓋語法語意的、物件模型的、專家經驗的、設計樣式（design patterns）的、入門的、進階的，作為參考工具的…。拿 GP/STL 來說，就得有 GP 泛論型的、STL 源碼剖析的、STL 應用大全的、STL 規格大全的、STL 組件設計的、其他泛型技術的…。拿Java 來說，就得有語言核心的、物件導向的、多緒編程的、圖形介面的、網路應用的…。對生手而言，不先把底層的東西弄清楚就學習高層的抽象，必會成為空中樓閣，流于形式。對熟手而言，缺乏抽象思維，意味層次上的停滯。 寫作、翻譯、乃至於出版全體系好書，真的是一件需要目光長遠、意志堅定、帶點理想色彩的人，才做得起來的志業。 如果這樣的人，這樣的出版社，沒有得到大家理念上和實質上的支持，誰會投入這種傻事？ 我個人一向是高品質高價位的堅定信奉者。高品質高價位是生產者經營的最大誘因。因為努力做出了高品質，所以得享高價位帶來的高利潤，天經地義。否則誰要費心去做高品質？慈善家嗎？傻瓜嗎？ 對於消費者，高價位當然令他不舒服。但是你應當思考是否物有所值，甚至物超所值。拿英文書為例，USD 49.95 一本的 The C++ Standard Library，或是 USD 49.95 一本的 Generic Programming and the STL，完全物超所值。當我了解這些書的價值，就算他們再貴兩倍，我也要買。有人拼死吃河豚，我可是要拼命買好書。現實地說，眼下「知識經濟」喊得震天響，好書帶來的知識不正是賺錢工具嗎？對賺錢工具小氣，是不是和自己過不去？ 下面是一封讀者來信： 相較日本無論是漫畫作家、文學作家或是偶像歌星、影星的客觀條件來比較， 在*，身為專業作家竟如此難為？有人可以連夜搭帳篷排隊買票看演唱會，有人卻可以論斤計兩地討論頁數與書價高低。或許他們不知道，一本介紹C程式語言的入門書，在德國索價100 DM (約NT$2000)。 因此我的德國同事們購書前必定徵詢意見或參考書評。書價雖不低，但其讀書風氣仍不亞於日本。 這裡點出了一個重點：書價很高，於是大家慎選好書，重視書評。下面是另一封讀者來信： 我是一名大陸的讀者，同時也是一名計算機的初學者。我在網上看到網友都十分推崇您的著作及譯作。知道您的作品《深入淺出MFC》第二版即將在內陸出版，我決定買這本書，並與華中科技大學出版社取了聯繫。從那裡知道您今年還會在大陸出幾本書，我非常高興，但在知道了您對價格的看法後，又有些失望。 大陸與台灣的經濟水平是不同的，作為普通的工薪階層，購買力也是有限的。我們這裡，各類圖書中計算機類圖書的價格是最高的，圖書頁碼的最高位與書價的最高位基本相同 -- 700頁的書，價格在70到80元之間，1000頁以上的，價格在100元以上。這是目前大陸書價的大體情況。如果按您所說，350頁，書價80元，在這裡算是很高的價格了，這種價格的書，只能看，不能買。 "春蠶到死絲方盡，蠟炬成灰淚始干"，教師工作被我們看成很神聖的職業，燃燒自己，照亮別人。我想您出書的目的，也是想讓更多渴望知識的人受益于它，少走彎路。作為讀者，我們也希望能夠看到更多更好的書。但是在一定歷史時期內，購買力與價格應當有一個平衡，350頁80元的價格確實太高了，如果能夠降到60元以內，我相信大多數讀者可以接受。 您的書的品質很高這是大家的共識，從價格上應當與其它書區別開來，但書價也不宜太高。名牌服裝走高價位的路線，當然可以提高它的身價，顯得它檔次很高，但是太高的價格使它脫離了主要的消費群體，大多數人只能在口頭上談論它，卻只有極少數的人會把它穿在身上。書籍與名牌服裝不同，只有經過很多讀者長時間的閱讀之後，才能夠證明它的價值，如果很多人都知道侯先生的書質量很好，但是卻很少有人讀過（因為價格問題），那豈不是一種悲哀。 我最不樂意看到「xxx 頁的書，售價 xxx 元」這種觀念。一本書的價值在內容，不在頁數。真要這麼算，每本書我們都應該檢視一下其字型大小、行距字距、硬拷圖多寡、留白多寡 -- 因為這些都關係著頁數。如果大家都接受頁數和書價的固定比例，肯定會有大量浮濫的書跑出來（不就是現在的情況）。 不必這麼累。一本書值它的價，就買；不值它的價，就別買。很簡單的邏輯。 我們難道能夠拿著尺衡量一件亞曼尼用了多少碼布，來決定它的價格嗎？或是拿著尺衡量一張梵谷是幾號，來決定它的價格？我能夠說因為我畫的繡球花比梵谷的鳶尾花大兩倍，所以我應該賣他的兩倍價？ 買東西不能光看有形；那無形的往往更重要。買書不是買紙。正確價值觀必須建立起來。 當然很有可能你認為買名牌服裝或名畫的人都是瘋子。你要的只是布和框。那表示那些物品在你心中不值那個價。很好，你有你的評價，你有你的選擇。 我不打算在「引喻」（例如名牌服裝或名畫）上面多著墨。引喻有顧此失彼的時候，筆戰都是這樣打起來的。各位知道我要強調的是什麼。 350頁的書，不應該一定賣 80元，也不應該一定不賣 80 元。這要看350頁的含金量有多少。況且我從沒說過侯捷有 350頁的書要賣 80元。但所有的可能都存在。350頁可以是180元，也可以是80元，也可能 530 頁連 18 元都不值。請不要再以頁數做為書價的依據了。 教師的工作很神聖，但「燃燒自己，照亮別人」太沉重。「燃燒自己」，呵呵，說起來多麼容易，做起來多麼痛苦。某人的工作對眾人有益，他會很開心。但你要他燃燒自己照亮別人，除非聖人，否則不幹的。我很樂意照亮別人，卻不想燃燒自己。燃燒自己，我只能照亮別人五年；把自己照顧好，我可以一輩子照亮別人。抬出大帽子，會讓有能力寫作好書的人畏懼不前。 請大家接受這樣的觀念吧：書的價值在內容，不在厚薄，不在頁數。價值影響價格，價值帶動價格。接受這樣的觀念，便是對好書的所有出力者致上敬意與實質支持。如果大家慎選好書，10 本垃圾書的價格支撐兩三本高價（其實是適價）好書綽綽有餘。走編程這條路，誰手上沒有 10 本 20 本垃圾書！當大家慎選好書，支持好書（儘管它價格較高），就會帶動書評風氣，帶動優良寫譯風氣。這對所有的人都好。不需有人燃燒自己，大家都被照亮了。 當然，高價位的薄書很可能帶來盜印與影印的歪風。但無論如何，我是堅持己見不會退縮的。如果大環境真的無法提昇，好書離開了，好人退出了，最後損失的是誰？ 不論各位相信不信，侯捷企圖以個人影響力（如果有的話）建立優良的技術寫作大環境，對*如此，對大陸也是如此。「問渠安得清如許，為有源頭活水來」，要讓大家有更多好書可讀，就要有源頭活水注入；要有源頭活水，就要有更多誘因吸引更多才能之士到技術寫譯領域來。更多的誘因是什麼？讓他們知道，好作品可以突出，可以區隔（講白了就是有好價格），不會牛驥同一皁，這就是一種誘因。不，這不算誘因，這根本是一種基本道理。 優質的書使讀者受惠，優質書籍所帶來的高報酬使作者、出版社受惠，並吸引更多優秀人才到這個領域。形成一個良性循環，大家都受惠。 另外我要建議大陸出版社，善用你們獨特的「影印版」。*的計算機類翻譯書，由於也是良窳不齊，窳多於良，曾有讀者開玩笑建議，出版社取得授權後，不要譯了，直接以原文出版，讀者看得高興，售價又得以大幅下降。想來這就是大陸的影印版（在*是不許的）。既然翻譯書已到了千夫所指的地步，何不乾脆多多引進影印版？不是要搶短搶快嗎？這個最快了，讀者也多一種選擇。 翻譯出了什麼問題計算機翻譯書的一個大問題是，譯者沒有時間（或正確的心態，或足夠的中文能力）將譯稿一看再看，一改再改。中文有一個缺點，那就是名詞本身表現不出複數，動詞本身表現不出時態。多數時候這可能不是很重要，因而可以忽略。但某些時候它們佔有關鍵地位，於是一個精準的英文句子，往往需要譯者額外花很大的心力，才能精準地以中文表達出來，那麼譯者就得有足夠的時間和足夠的中文能力。而唯有譯者在專業技術上具備足夠的素養，才能夠看出某些隱微地方對理解之正確性有關鍵性影響。 英文裡頭的子句如果又臭又長，別說中國人，老外也得費一番手腳才看得懂。看看這個（C++ Primer 3/e, p730）： [code..] where the conditional test if (this != &rhs) prevents assigning a class object to itself. This is particularly inappropriate in a copy assignment operator that first frees a resource currently associated with the class in order to assign the resource associated with the class being copied. 我的譯文是： [code..] 其中的條件測試 if ( this != &rhs ) 避免將 class object 指派給自己，因為「自己指派給自己」這個動作，對於那種「先將目前繫結於自己身上的資源釋放掉，以便稍後將該份資源再繫結於即將被拷貝的那個 object 身上」的 copy assignment 運算子而言，尤其不合適。 只需加幾個引號，標示出子句，就好看多了。尋常一樣窗前月，才有梅花便不同。如果沒有引號輔助，你試譯看看會是什麼樣子。別對我說「根據教育部規範，上下引號只適用於強調專有名詞或特殊語氣…」，規範是死的，人是活的呀。只要能夠靈活而正確地表現出文意，就是好辦法。小平同志不是說，管它黑貓白貓，會抓老鼠的就是好貓嗎。阿波羅13號登月計劃失敗時，太空艙內的備用排氣罩規格不符，地面控制中心要求宇航員必須想辦法將方形罩子塞進圓形的排氣管中，否則大家都得因為飽食二氧化碳而死於太空。這時候還想什麼規範？腦筋靈活點。 另一個中文表達的大缺點是：動名詞不分。操作是名詞（operation），也可以是動詞（operate）；實現是名詞（implementation），也可以是動詞（implement）；參考是名詞（reference），也可以是動詞（refer）；請求是名詞（request），也可以是動詞（request）；委託是名詞（delegation），也可以是動詞（delegate）。當動詞名詞混雜一起的時候，就造成閱讀上的錯亂。於是你可以看到這樣的句子（取材自《設計模式》p14，李英軍等譯，機械工業出版社）。請諸位先看原譯，能否就中文語句結構分析出其大致意思： (1)原譯：只有當委託使設計比較簡單而不是更複雜時，它才是好的選擇。 (1)侯譯：只有當「委託方式」簡化了設計，它才是一個好的選擇。 (1)原文：Delegation is a good design choice only when it simplifies more than it complicates. (2)原譯：委託方式為了得到同樣的效果，接受請求的對象將自己傳給被委託者（代理人），使被委託的操作可以引用接受請求的對象。 (2)侯譯：為了以「委託方式」獲得相同效果，「請託（request）受理者」將自己傳給被委託人，使自己得以讓「被委託之操作行為」取用。 (2)原文：To achieve the same effect with delegation, the receiver passes itself to the delegate to let the delegated operation refer to the receiver. 我沒有一別苗頭之意。我的譯法不見得最高明。況且翻譯一整本書所需的各種前後呼應的考量，遠比光譯一兩個句子複雜許多。只是既然我提出了問題，我總要提出自己的解法，給大家參考評量。對於機械工業出版社願意出版這樣一本經典，李英軍先生等人願意翻譯這樣一本高階而吃力不討好的書，我是帶有敬意的。 另一個翻譯上的問題就是大家往往在計算機類書中硬套一般字典查來的詞彙，沒人敢突圍。要知道，一般字典並未考量電腦技術，更不可能考慮到上下文（context）。太多人抱著少做少錯，不做不錯的心理，一昧緊跟字典，不敢變動，才會造成目前許多譯詞不夠理想，卻動彈不得。我印象最深刻的是這幾個字： instance：*和大陸均有不少人譯為「實例」。這個「例」字根本不好。*甚至有人譯為「案例」，更不妥當。為什麼這麼譯，因為字典查來的現成詞彙是這樣。所謂 instance 就是根據某個東西（可能是實物，可能是某種表述）產生出來的一份實際物體。我認為譯為「實體」是很合適的。根據 class 產生出來的便是object實體，根據 class template 產生出來的則是class 實體，根據 function template 產生出來的是function 實體。根據可執行檔（executable files）產生出來的，則是一份 process 實體。 paradigm：*常譯為「典範」。為什麼？喔，字典查來的現成詞彙。有時候這樣譯有點道理，例如 paradigm shift 叫做「典範移轉」。問題是，何謂「典範移轉」？很難望文生義是吧。把 generic paradigm 譯為泛型典範，更是令人不知所以。我們日常用語裡也有「典範」一詞，我們會說某某人是國家社會的典範，那和計算機術語裡頭的 paradigm 根本不是同一個意思。根據 paradigm 在計算機術語中的實際意義，我把它譯為「思維模式」 — 典型的、根本的思維模式。 讀者來了這樣一封信： 我向您討教一個翻譯風格的問題。正如您所說，英文技術書籍最難在長句子，因為英文的句式組合形式比中文大大豐富，理解起來已經費力，翻譯成順口的中文更難。我有時遇到這種句型，切分組合，翻來覆去掂量，還是覺得中文不忍卒讀。您認為此時 (1) 我可不可以放棄 "信" 而求 "達"，也就是說略掉部份句子成份以保全譯句的通順？還是 (2) 務求將原義表達出來，寧可中文句子不順暢也在所不惜？更有甚者﹐有時 (3) 某些句子無關宏旨，卻異常難譯，可不可以乾脆略過不譯？您的看法是什麼？ （各位有沒有注意到，這位讀者的中文很好。「切分組合，反覆掂量」這幾個字用得多精簡傳神）我的看法是，譯者有權利也有義務通權達變，但也必須有這份能耐才行。因此你的第一個問題我認為可以，你的第二個問題我認為不可以。你的第三個問題我認為可以，但需謹慎為之，莫因譯者本身水平，犧牲了某些東西。 科技翻譯應該務求義譯而非字譯。信與達，應從整個句子或甚至整個段落來看，不是從一個個單字來看。技術文章和文學多有不同，譯者最重要的任務是正確傳達知識，並儘量減少讀者的吸收困難。 到底彈性的底限在哪裡？我這麼認為，譯者於技術層次上愈有把握，便享有愈大的彈性。只要技術層次夠，有把握正確了解並傳達了原作者要表達的技術，那麼，文字上不必字字拘泥。 中文在科技表達中並非一無是處。中文有一個優點，就是資訊密度高，很多時候精簡漂亮的一行中文，可以表達出「子句夾帶子句再夾帶子句」的三行冗長英文。中文有優美的詞藻與取之不盡用之不竭的典故、成語、俗諺，如果善用它們，冰冷的技術文字一下子就能有閱讀的樂趣。一本爛譯本，會讓讀者詰屈聱牙，痛苦至極；但是一本好譯本，能使人如沐春風。 容我說一句，正確的心態、足夠的時間、充裕的中文表達能力、水平以上的專業素養，是造就好譯本的基本元素。現今情況如何？話說回頭，好譯者的報酬幾何？你願意多花點錢表示你對他們的付出的認同嗎？ 健康的選書心態以下談到選書的心態和作學問的態度，由於都以讀者來信展開討論，因此避免不了提到我寫的《深入淺出MFC》。我要談的問題，其實不侷限於某一本書，或某一種技術。就像這篇文章先前舉的許多例子一樣，都是可以放大來看的。 讀者修書一封如下： 2個星期前好不容易讀完了您的大作，讓我對MFC的認識多了不少，不過一點遺憾的是從您的書裡並不能學到如何寫一個具體的程序，僅僅是明白了MFC的“包裝技術”。本來我還以為又上當了呢﹗因為我買這本書的目的就是要學習用MFC來做程序的...一個偶然的機遇讓我得到了 Jeff Prosise的《programming windows with MFC》﹐這才發現老師您的書是多麼的重要，假如沒有您的《深入淺出MFC》我又怎麼可能programming with MFC呢？...您的書救我于水深火熱之中，帶領我沖破MFC的條條封鎖線。 雖然這位讀者最終對侯捷和侯捷的書以感謝和讚美作收，但我頗有感慨。 讀者往往以最直觀的態度來審視一本書的價值，以最直接的方式來表達他的愛憎。但不能凡是不需要的，一律視為灌水；凡不符合需求的，一律視為欺騙。這不是一種健康的選書態度。即使你最後並沒有發現《深入淺出MFC》「是多麼的重要﹐救我于水深火熱之中﹐帶領我沖破MFC的條條封鎖線」，這本書又何嘗在書名或內容欺騙過你，使你「以為又上當了呢」。再者「我買這本書的目的就是要學習用MFC來做程序的」，可是你若連MFC與application 的第一線接軌都不了解，照著葫蘆畫瓢，能寫出多好的程序？ 我不是責怪這位讀者，只是這封來信代表某些現象，讓我心有感慨。下面是另一種偏激： 您的書我覺得有些無用的原理講的太多了! 你所寫的並不是真正的教人怎麼用VC,而是教人VC運做是怎麼樣進行的! 其實很多讀者真正關心的問題並不是在這裡! 而是在怎麼對用VC設計出真正出色的程序! 讀者永遠只想要看自己想看的內容，這一點很自然。但是你不想看到的東西並非就是「無用」，它對別人可能「很有用」。再說，連MFC與application 的第一線接軌都不了解，照著葫蘆畫瓢，我不知道你能寫出什麼「出色的程序」。只要出一點差錯，你連除錯的能力都沒有。開車是很簡單的，開車上路遇到各種突發狀況而能應付並排除障礙，才是困難的地方，才是技術的表現。 下面是兩封*讀者的意見，有點年代了。當然我必得先說明，抱持這種態度的讀者，比例大約在百分之零點零一。 讀者意見一 這本書包裝太厚。不該有的東東太多，附錄A所列的無責任書評，在我想來也是多餘。因為這篇書評在RUN!PC早有提及，後來也出了無責任書評第三集，因此實在沒有這個必要。想來是侯先生要增加書的厚度，有以致也。 讀者意見二 書評不應該放在這本書裡吧! 因為這些東西而讓書太厚實在有點…這些灌水的東西共計有： (a)1-16頁的讀者來函：共16頁 (b)超長的序，嗯，這應該沒有關係 (c)843-872頁的無責任書評：共30頁(其實裡面有一些發人省思的東西，還好) (d)873-914頁的Scribble原始碼：共42頁(這最嚴重，幾乎沒必要的東西) (e)915-920頁的VC範例程式一覽：共6頁(很可惜，如果再多加發揮的話很有用，但是侯Sir只是列個標題，連說明都是英文，和看Help檔沒什麼差別) 共計：94頁 不是我無聊找碴，您可曾看到有哪本書有將近一百頁的贅肉?更別題書中動不動就列出四五頁的原始碼了。這些在光碟上都有，何必浪費紙張? 不過消掉這些贅肉，這本書還是有它的價值…至於書中缺少的部份，我認為要看您如何去定位這本書。總不能要求一本書把所有Program的東西講完吧! 以探討MFC的內部而言，本書沒什麼好批評的了。總而言之，這本書該不該買，我想還是肯定的。但是如果書能瘦點、售價能低點，那就更好了。 說來說去，原來是為了「如果書能瘦點、售價能低點那就更好了」。這便是頁數和售價牽扯觀念下的可憐受害者，他們扭曲了書籍的價值，也嚴重扭曲了自己該有的正確價值觀。如果我告訴這些讀者，少掉那100頁的所謂「贅肉」，售價一樣是 NTD 860，恐怕他們又要對這些「贅肉」熱情擁抱來一個親親了。真的是這樣，這本書是先確定價格，最後為了給讀者更多資訊和更大的方便，我才加上那些「贅肉」的。 這一類讀者，站在敵對的立場，看待出版社和作者，幻想每一個人都在覬覦他的錢包，並且認為對他無實質幫助的每一頁（可能只是因為他已看過）都是被刻意灌水的結果，都是為了欺騙他的鈔票。這樣的讀者在杯弓蛇影的壓力之下，忘記了沒有任何一本書是為個人量身打造的，也忘記了其他人可能有不同的需求，完全以自我為中心。 這一類不成熟的讀者，實在是當前劣品充斥下的犧牲者。老實說我個人並不喜歡他們成為我的讀者。只是，讀者有選擇作者的權利，作者卻沒有選擇讀者的機會。 正確的作學問態度前面兩篇來信透露出一個疑惑，《深入淺出MFC》是不是一本對VC編程有幫助的書。我不是要在這裡夾帶推薦該書（相信我，我不需要如此），而是想透過MFC與VC的關係，引申談談作學問的態度。如果「作學問」太高遠了，那我們來談談「學習」的態度吧。 以下是一封讀者來函： 我有個疑惑，想請你幫助。我們今天學C/C++，明天學MFC﹐OWL(如果流行的話) 後天學C#﹐JAVA...如果 WINDOW 被 X WINDOW 淘汰，豈不是都要從頭學過？有沒有必要把一切搞得如此精通？同樣的目的，為什麼不用更方便簡單的快速RAD開發工具？而非要以鑽研繁雜作為樂趣？和體現水平？是否搞錯了方向和目標？我認為這正是目前大陸（台灣我不了解）軟件開發的一個錯誤的方向。 所有同質的技術都有累積性與共通性。信中提到的三組東西：MFC, OWL, 或是 Windows, X Window, 或是 C++, Java, C#, 都有類似性與共通性。技術是會累積的，有了某種經驗，學習新技術會快很多。經驗愈多，學習愈快。所以我常喜歡說「觸類旁通」。如果每種技術都得從新學習，大家三五年就得歸零一次，人類世界就不會在 20 世紀像爆炸似地進步這麼快。 「有沒有必要把一切搞得如此精通﹖」我的回答是：看個人需求與定位。基礎知識的精通，是做為應用的一種過程與手段，而不是目的。如果你不需要通過這樣的過程，就可以把你要做的事情做得很好，那麼當然你可以跳過這個過程。我所知道的是，許多許多人必須先有這樣的過程，才能夠良好達成期望目標。我自己也需要通過這樣的過程（否則寫不出這樣的書）。這不是你所謂的「鑽研繁雜」或「體現水平」。 既然信中提到RAD，我也談談我的看法。我曾經寫過一篇文章，把RAD喻為「匹夫無罪，懷璧其罪」（見侯捷網站 1999/01/26 懷璧其罪 RAD），建議各位看看。我很贊成使用RAD。我書寫MFC書籍，探討MFC技術，但從來沒有認為它最好，或不好，我只是要幫助那麼多使用MFC的人。和Bjarne 的態度一樣，我對諸如此類的工具評比活動一點興趣都沒有。我樂意當一名觀眾，但從來不評比（應該可以說，也沒有能力評比）。 RAD 的情況，可以拿汽車做比喻。現今誰開車還需要知道齒輪箱、傳動軸、離合器、引擎點火原理、火星塞呢？但是滿街開車人誰又能夠表演360度大迴旋？要到達「車手」的程度，就必須對車子的原理有相當程度的瞭解。同樣是開車，洗拿（F1方程式冠軍車手）和侯捷兩人發揮車輛功能的程度，絕對有天壤之別。我認識的所有慣使RAD 的高手，無一不是有底層深厚功力。以RAD始，以RAD終，斷不能在技術上有所太大長進。你的生涯將是空白的五線譜，沒有高音，沒有低音，永遠的水平…。 RAD是要用的，有好工具不用，和自己過不去。但是使用RAD的同時，對底層做更多的瞭解才有助於在某種情況下脫困或自助。這和 STL 的運用也一樣。會用STL，是一種檔次。對STL原理有所了解，又是一個檔次。追蹤過STL源碼，又是一個檔次。第三種檔次的人用起 STL 來，虎虎生風之勢絕非第一檔次的人能夠望其項背。 學習某種工具，及其背後代表的某種技術，究竟要鑽研到什麼深度？唔，答案視你想扮演什麼角色而定。「F1方程式車手」和「半夜三點才敢上台北大馬路的用車人」之間，有許多許多的層次，你自己定位自己。 有些人絕對*RAD，有些人又重新反省RAD。下面是另一封信： 我原本是一個一天到晚使用RAD工具的人...但是歷經了三個版本之後，我有一種被騙的感覺，因為處在這個環境中，似乎是投身在別人設好的一個圈套裡！這種東西會讓人對於『了解 OS 內部運作以及各種規範與協定的基礎層面』的慾望慢慢減低至零。今天為了突破某一個元件的限制而自己寫了一個元件，明天新版RAD內附元件就出現了比自己寫得還要好的東西。到了最後，自己不想寫，只想等別人寫給你；要是別人不寫，你就徹頭徹尾地喪失了一項能力...(天曉得要等到何年何月)，要不然就是官方給的元件功能少東少西。不只這些！最讓我受不了的是，我竟然發現：程式用這種方式去寫，簡直就比用Office 還要簡單，深入的思考幾乎是零...。 我在「懷璧其罪 RAD」一文中是這麼回答的： 1. RAD 並非罪惡，而是優點。要怎麼用它則是你自己的問題。我有兩位朋友是 Delphi 專家，他們可以使用 Delphi 做任何事情，沒有任何你想像中 RAD「該有」的限制。 2. 果真能夠「寫一個程式，比使用 Office 還要簡單，深入的思考幾乎是零」，並不是壞事。大家都能夠隨手寫個小程式解決手邊幾個小問題，是為component software 以及 RAD 的大貢獻。但你的形容太誇張了，目前的 RAD 還不至於美好若此，總還需要一些程式邏輯和程式語言的基本訓練。真到了你說的那一天，我覺得是件好事而不是壞事。只不過，那樣子完成的程式，都需藉助現成的元件。如果要突破現成的框框，就得有更深的功力。無論如何，RAD 不會是你的絆腳石。 這類話題很難一言以蔽之。總之，優秀的技術者一定需要一個向下沉澱的歷練，通過了這層歷練，有了紮實的基礎，就可以向上浮昇，開始以抽象的思考，抽象的語言、快速開發工具來進行高層次的開發工作。這時候運用 RAD 工具，當能如虎添翼。 所謂百鍊成鋼；鋼的形成，是將鐵塊不斷鎚打，不斷回火，不斷淬鍊。做為一個程式員，本身技能的層次，和回火淬鍊的次數有密切關係。 讓我們再回頭談談基礎建設。很多資訊科系在學學生對學校所開的課程，非常不服氣，非常不屑，認為對編程能力一點幫助也沒有。首先我要說，編程、軟件開發並不是資訊系學生的唯一出路。資訊領域何其廣泛，編程只是其中小小的一支而已（但對就業市場而言則是大大的一脈）。其次我要說，基礎理論課程並非對你的編程一無是處 — 不是無用，只是未到用時。有些科目的影響非常直接而深遠，例如對編程最重要的兩門課：資料結構（data structure）和演算法（algorithm），這兩門課對邏輯思考與實現能力的訓練，有關鍵性的價值。沒有這兩門課做底，任你 C/C++/Java 多強多行，也寫不出個好程式。其他基礎理論課程也都各有用途，會不會在你未來的編程生涯中帶來幫助，那得看你編哪一種程。就業與學校所學，不必然會發生關係，不必然不會發生關係。 編程能力強的年輕同學，容易孳生一種趾高氣揚的惡習，看這不順眼，看那不順眼，教授都老朽，同學都可笑。問他為什麼，哦，因為「他們的編程功力都不如我」。可笑的正是你自己呀。 編程實力的培養其實很容易的。我所謂容易，是指不需借助外力，純粹自修就幾乎可以做到。再沒有比這更幸運的事了。當然你的進修必須按部就班（在我的專長範圍內，我寫了很多讓你前進時有所依循的文章，都在侯捷網站上）。任何高深的理論，只要實際操作過都可以霍然理解，編程的實作又有什麼難的。數本好書，一部電腦，一些必要的工具，全部搞定，只欠一股「頭懸樑錐刺股」的苦讀精神。實力進展到一個階段後，我非常鼓勵你追蹤名家源碼（有人指導更好）。司馬相如說：能讀千賦則善賦，能觀千劍則善劍。侯捷說：讀過千賦亦能賦，觀過千劍亦能劍。 最後我還要說，學校（尤其大學）原本不是職訓所。但是關於人格的培養，思想的啟迪，視野的開拓，現今言之，恐怕是陳義過高，沒人愛聽了。 學校肯定有學校的缺失。其一是課程太過理論，高來高去。以大學生的程度而言，太過抽象的東西他們是沒有能力接受的。但是要化抽象為具象，化繁為簡，可得有非常深厚的實力才行。其二是教材、教具、教師太過陳舊，跟不上時代。我印象最深刻的是，*BBS時常有學生問 Turbo C 3.0 上的問題。我的媽呀，C++ Standard 都出來兩年了，學校還在用TC3.0。倒不是說一定要追最新最炫的工具或產品，但是TC3.0 距離 C++ Standard，有月球到地球的距離吧。用這個編譯器，可想而知老師教的是什麼內容，可想而知老師本身跟上外界脈動的程度。如果新工具新產品都很貴，顧及學校經費，我們也能體諒。可 Borland C++ 5.5, GNU C++ 2.96, TAI C++ 都是可以免費下載或限期試用的呀。它們對 C++ Standard 的實現，比TC3.0 好太多太多了。 這就涉及學校教育裡頭最重要的關鍵：師資。說句實在話，大學裡頭有不少老師，書是唸得很棒，就是沒有實作經驗，更沒有業界經驗。因循苟且之念一動，萬年教材一攤，同學們就只有自求多福。 自救之道當然有：你必須更勤奮。勤奮看書，勤奮發問。勤奮搜尋好的導師和好的讀物。或許天道酬勤，就讓你碰上一個傳道授業解惑的貴人，就讓你知道一本必讀的經典，並且就讓你找到它。 說到勤奮發問，讓我發出本文的最後一聲感嘆做為結束。*大學生在「表達能力」這一點，程度普遍低下幼稚。能夠條理分明把自己的意思表達清楚的，十分罕見。反映出來的，就是怯怯懦懦，理不直而氣不壯。私底下聲若洪鐘，要他站起來公開表示意見，卻如細蚊之嗡嗡。不論口語或文字，用詞普遍地「俗」。大陸情況，就我的印象，以及我收到的讀者來信，感覺好很多。以前*的說法是，因為大陸鬥爭厲害，人人得有一口利嘴以求自保。但*已過數十年，我看大家的表達能力普遍還是很不錯，是不是求學階段中曾經特別重視這個？ 發問的能力影響學習甚鉅。善問者使人繼其聲，善教者使人承其志。我常自詡為一名善教者，但如課堂上兼能有一名善問者，高潮迭起，全班受惠。