文章：Ten Great Books 十大好書
日期：2004.11.18
作者：Steve Yegge
作者的部落格（2006至今）：Stevey's Blog Rants
作者舊的文章（2004與2005）：Stevey's Drunken Blog Rants
這篇文章很久了，不過我很喜歡看這種別人列出來的書單，總覺得透過這個可以了解寫的人的背景。還有，原文後有一些作者同事的回應，我就沒翻譯了。
注意，作者寫這篇時任職於Amazon。這裡有作者的背景簡介。
謝謝小夏回答我一些翻譯上的問題，特別是星巴克咖啡行話。
十大好書
最近我努力增加閱讀的量──所謂"最近"大約是過去的兩年來──試著去學習一些我以前似懂非懂的地方。
要學習新東西新技術時，看歐來禮(O'Reilly)的書似乎是最佳途徑，因為提姆（歐來禮的創辦人與執行長）知道一點：容易親近的書才是讀者想要的，換言之，第一遍就可讀懂的書，而且不會假定你已經知道一堆專業偏僻的哩哩扣扣，所以當我需要學最新的Algol家族的程式語言、或是Adams家族的分散式運算協定、或是Lisp家族的XML相關技術（喔，不！我怎麼說漏了嘴…），就是該拜訪歐來禮的時候了。
不過，歐來禮在數學、計算機科學(computer science)、工程、普及科學、以及其他類似的非實用性領域方面並沒出什麼書，或許是因為這類書籍銷售量低，以至於當我要學習這種有用卻艱難的主題時，就需要勇敢地踏進那些讓人怕怕的"其他出版商"的地盤。
看不見的出版商
你是否發現偶爾就會有出版商入侵你的腦細胞，讓你清楚地意識到它是一家超棒（差）的書商？
例如：我認為SAMS這家書商真是差勁壞透了，我買過幾本，每次都被書的品質嚇到，它出的書基本上都有多個作者，每人負責不同的章節，很明顯地作者們都不知道彼此的存在，所以常常造成同樣的東西重複出現在不同章節──有時甚至使用了不統一且有衝突的術語或是徹底矛盾的說法；我剛剛拜訪了它的網站確定是否為Sams，沒錯，是它，所出版的書大多書都有兩個到十個的作者群。相信我：離它們遠一點就對了。
至於其他（非歐來禮）出版品質穩定的技術性書籍的好書商：嗯…喔等一下，我知道的──我想到了，就快了…就在舌尖了；就是類似歐來禮的那種…唉，我忘記了。
嗯，我想我們有Sun Press跟Microsoft Press，不過奇怪的是，他們重心都擺在Sun或Microsoft自家的技術，所以你不能真正地相信他們在出書時是不帶偏見的。
啊，想到了！那家出版"Hacks"系列的書商，你知道的，Google Hacks，Excel Hacks，Amazon Hacks…相當酷，喔等等，*嗯哼*，那也是歐來禮(O'Reilly)，當我沒說。
喔！那新的"Developer's Notebook"系列怎麼樣呢？那家出版商肯定有很務實地思考過該出怎樣的書，例如Java 1.5 Tiger: A Developer's Notebook──這本不錯，即使我買下的唯一原因是去看看是否可以寫列舉(enums)的子類別(subclass enums)，結果作者居然還反問說是否有哪位讀者想出怎麼做沒，嘿嘿，不錯還是本好書，哪家出的？
我給你三次機會；前兩次不算。
歐來禮(O'Reilly)就是技術性書籍界的星巴克/麥當勞，你很清楚書的品質是穩定好的──不必然是超級好的，但是穩定的，而且更重要的，你會得到很一致性的閱讀感受與經驗，你知道什麼是可預期的，封面上有個大大奇怪的生物，那是可預料的，他們不會假設你懂任何數學，這真棒啊，因為我現在都用桌上計算機(M-x calc!)在算所有的算術；除了最低限度的英文程度以及你沒有太多時間可以花在這本書上，他們也不假設你懂其他東西，就好像星巴克跟麥當勞。
是還有其他出版商啦，你認得出他們的名字（或是封面的風格），Addison-Wesley是家不錯的技術性書商，John Wiley也是，可是我必須轉頭檢查一下書架才記得起他們，歐來禮站在不同的高度上；在討論時可以很放心地使用這名字，因為你可以肯定其他人也知道歐來禮。
這不常發生在技術性出版界；的確在科幻小說(Science Fiction)界，至少當我還是個孩子時，書商的重要性足夠到讓你記住他們是誰，如果Lester Del Rey出版某書，那你就知道這本會是青春期青少年的重要讀物──去看看Piers Anthony所寫過的每本書吧，Ballantine Books雖文化水平略嫌高一點，但同樣出色，還有Daw books，特殊的黃色書背，每本幾乎都值得買；檢查一下我的書架，我看到Enders Game是Tor出的，因為過去二十年來我已經不太常看科幻小說，所以把Tor跟Daw搞混了，但我記憶中他們都是很好的書商。
為什麼技術出版界幾乎被一家出版商所佔有呢？（為什麼不是Amazon出版厚厚的橘色與黑色的技術性書籍呢？人們會買來讀啊，至少到分辨出好壞之前，我們可以出版我們也不懂的servware技術，而且還是會賺錢。）請容許我大膽猜一猜，原因是，為了判斷出什麼才能造就一本好的技術書籍，你自己本身要具備相當的技術性，或至少有些技術性的常識，我以前就提出過這論點：你一定是為自己創造偉大的事物，不是為別人，要不然就不會偉大。
十大好書
我原本打算將這篇部落格命為"十大挑戰"，談談十本我希望早就該讀過的書，我的意思是，十本我明知該看的書，因為我清楚它們對我有幫助，但我卻還沒設法讀完。不過我想了想，我應該先列出十本極棒的書，儘管我過去一直在酒醉時邊流口水誇誇其談物件導向程式設計、多重執行緒、還有馮紐曼架構的壞話。（嘿，這些都應該算是我們應該致力於其上的目標才對，沒錯吧？別讓我的墓碑上寫著我一點都不實際啊...）
所以囉，以下是十本我很喜愛的書單，而且我會推薦給每一位電腦程式員，不管他們想用什麼語言或平台。注意：我只挑我真正完整讀過而且常常回頭翻閱的書，我確信有很多大作可以擠掉這份清單中的書，只不過我太遜咖而沒辦法讀完它們，將來我會寫另外一篇來討論這些書。
And with that, the envelope, please...（譯註：這裡完全不知道怎麼翻。）
#1) The Pragmatic Programmer: From Journeyman to Master by Andy Hunt and Dave Thomas.
雖然我用了三或四小時就可火速地讀過一遍，也沒有得到大量的新知，但這本是我最喜愛的程式設計相關書籍之一，重點是讀這本讓我感到愉悅，書中講的都非常有道理，而且這本書幫我複習了一些好的程設習慣，加深印象。
本書的主要重心在教你成為一個寫程式又快又好的程式員，以及如何在做苦工鍛鍊技巧時享有樂趣，例如，書中建議你學著不看鍵盤用十指打字，還有選一個強大有擴充性的編輯器，並學習寫擴充元件，還有選用一個支援後設程式設計(metaprogramming)的語言，這樣才不會因為遷就語言缺陷而必須使用數萬行的程式才能達到想要的功能。
聽起來有點像我某幾篇部落格的論點，不是嗎？
老實說，我擔心這本書是白做工，這本可能是那種，你要不然早就懂得且同意它說些什麼，要不然就是永遠不會認同其內容的那種書。
從本書挖到一些郵件論壇(mailing lists)，我發了一些建議上去，從所謂的工程師得到了回應，他們自豪地聲稱，大言不慚地指出，他們四年來就算沒寫script還不是平安無事，然後他們又發信到同樣的論壇，詢問是否有人知道可以把註解中的某名字做全域性的變更這樣功能的重構工具(refactoring tool)，或者當整個社群告訴他需要改名一個識別字，因為它"已經在太多地方使用了"，他們也不願聆聽這樣的意見。（是的，我保留了這些信件，放在我的"不合格的SDE們"資料夾）
譯註：SDE應該是指software design engineer，Amazon公司的職位。
或者當討論後設程式設計(metaprogramming)以及各種精簡程式碼的技術時，某些人會突然啪的一聲插話打斷，開始大叫大嚷地說著任何一本OOP的書都會告訴你們唯一需要知道的技術就是EJB。
我把這本書放進書單中的前十名，希望那些還沒意識到實務練習在增進效率的價值所在的程式員們，希望那些不知道光想去學習新知這個念頭就可以讓他們遠離口水戰深淵的程式員們，可以讀一讀。這真的是本好書，讀起來也很快，書中所有的內容實際上都有其重要性，所以睜大眼睛在那些看似沒啥用的章節吧，那些就是該研讀的部份。
#2) Refactoring: Improving the Design of Existing Code by Martin Fowler.
在2003年10月我第一次碰到這本書時，我感覺到一種不舒服的冷顫感，這種感覺類似你剛剛發現五年來，你褲子都沒穿好掉到腳踝那而且就這樣去上班；隔天我隨意問了問周圍的人：「ㄟ那個啊，你已經讀過那本，嗯，Refactoring那本，有吧？哈哈，我只是問問你而已，我當然老早以前而不是現在才讀過」，我問的人當中20個中只有1個讀過，感謝老天爺原來我們所有人褲子都沒穿好，不只是我。
這是本精采的書，教你如何寫出好程式碼，這樣的書不多，或許可以說一本也沒有，學校裡基本上不教你如何寫出優質程式，而且在公司你可能從沒機會學，這功夫大概得花上數年，之後你仍可能缺了幾塊重要的觀念，我就是。
這本書討論的，是在個別函式(function)甚至函式中程式碼片段的規模下，討論如何寫出實際可運作的程式，開始時，先給你一支很醜不過可用可動的函式，然後一步一步引導你如何改成又乾淨又漂亮而不會改壞掉，某些技巧作用相當大，且很多可以自動化，本書同時也告訴我為什麼儘管幾近全力修改，我的函式還是變得又大又長瘤，然後給了我方法跟信心去改正。
書中以Java來寫範例，不過別因此卻步，同樣的觀念在各種程式語言都適用，我認識一個不懂Java的傢伙，讀過一遍後馬上開始把觀念套用在工作上，把他的Perl程式碼做重構(refactor)，我最近甚至還對我的Lisp程式碼做拆解(factor)然後重構(refactor)呢。
如果你已經是個資深工程師，會發現書中80%以上的技巧是你早已了解且不知不覺就在運用了，但這本書幫這些技巧取了名並客觀地評斷其優缺，我認為這樣很有幫助，而且此書拆穿了兩到三個我早先自己發現並且珍惜的技巧的假面具，不要為你的程式寫註解？區域變數是所有的邪惡源頭？這傢伙是不是瘋了啊？讀讀這本書然後自己判斷吧！
#3) Design Patterns, by Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides（也稱為四人幫(Gang of Four、GoF)）.
不可思議的一本書，在1995年初現身，提供了23道暫緩死刑金牌給那一群盲目的、在地上爬行的、沈醉於手工藝的C++世界的瘋子們，（你有注意到，"Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn"跟"Protected abstract virtual typedef'd copy constructor function"在水中聽起來怎麼沒什麼差別啊？沒錯，古老眾神們現在正在Redmond邊散步邊胡扯。）
譯註：Redmond是Microsoft總部所在。
嗯，其實只能說有22個，因為其實Interpreter pattern是為了博君一燦（圈內人才懂的梗）才加進去的；1994，準備出版這本書那一年，剛好是John Backus在1954年發現程式員厭惡所謂"編譯器(compiler)"這種東西的四十週年慶：
那個時候，大部分的程式員只用符號式機械指令來撰碼（有些人甚至用八進位或十進位的機械碼），他們堅定地相信任何機械式撰碼方式都無法產出靈性巧思，那種匠心獨具的巧妙是程式員感覺到他擁有而且工作時經常需要的。因此，下列敘述被視為真理："比起人類自行撰碼，編譯器只能產出極差效率的程式碼…" [John Backus in the 1954 Fortran report]說的對極了！用編譯器真娘啊，問問任何從Geoworks出來的人，在他們已經退出市場而你還找得到的話，我們通通用組合語言(assembly language)寫；很明顯的嘛，電腦時間比程式員時間還昂貴，而且好的程式員可以徒手產出比任何編譯器都還有效率的程式碼，if敘述跟for迴圈是給小男人用的，我們有"jcxz"就夠了。
程式設計世界中大部分還相信著組合語言才是王道的傢伙都已經走掉了（那是"死掉"的婉轉說法），今天他們的子孫（就是你！）領悟到編譯器是不可或缺的了，我們羨慕他們身處的時空，不過今日的程式員堅決地相信任何直譯式撰碼(Interpreted coding method)，像是Java或Ruby，都無法產出靈性巧思，那種匠心獨具的巧妙是程式員感覺到他/她擁有而且工作時經常需要的，以此類推。
Design Patterns的作者覺得這很又趣，機器變了，語言變了，可是人沒變，所以他們惡作劇地把Interpreter pattern納入書中，當做一種玩笑，一種任何胸上有毛的程式員都不能真正了解的玩笑，更別提有人會同意了。
除此之外，這本書棒極了！
#4) Concurrent Programming in Java(TM): Design Principles and Pattern (2nd Edition) by Doug Lea. 注意我遵循著Amazon對於書名不拘泥於字面的闡釋，把"S"從"Patterns"去掉了，除去愛國這點外我這個人就沒什麼好講的了。
談concurrency的絕佳著作，Doug Lea聰明地避開了Quantum Chu Spaces以及基本的算術，轉而聚焦在"明智合理的工程準則"，幫助你的多重執行緒(multi-threaded)程式盡量跑久一點而不用做文本交換(context-switching)的動作。呵，開玩笑的，應該是在有文本交換情況下盡可能跑久一點，測試一下你是否還醒著囉。
Doug寫的真不錯，至少在第二版時可這樣說；第一版讀起來就像是博士寫給博士看的，表示當時是寫給像似Google這種沒路用沒影響力的公司看的[1]，不過第二版就非常人性，因此封面的色彩組合從冷冰冰的似神祇的血綠色改成人性化的鮮血紅，我可沒蓋你。
只要你用的是馮紐曼架構的電腦，你就必須考慮如何在一台循序式(sequential)動作的裝置佯裝出平行(parallelism)的概念，那可不是三言兩語說的清的(nontrivial)。（"Nontrivial"是一個電腦科學的名詞，在水底下聽起來就像是"wgah'nagl"。）所以即使副標題寫著"in Java"，概念原理還是可運用到任何一種程式語言，包括Hasturese。強烈推薦本書。
#5) Mastering Regular Expressions, 2nd Edition, by Jeffrey Friedl.
清單上第一本歐來禮的書！封面上畫著一隻貓頭鷹；貓頭鷹眾所皆知有著，嗯，規律的(regular)，嗯ㄜ，算了。不是一定能看出歐來禮怎麼選動物的。
這是本好書的原因，跟所有歐來禮的書為什麼好是一模一樣的：讓腦袋沒那麼複雜的人以容易接近的方式來學習艱澀的知識，你有注意到"O'Reilly"在水底下聽起來像是"for Dummies"嗎？坦白說，我還滿自豪擁有數本"for Dummies"書籍的（出版商：IDG，相信是"IDiot's Guide"的縮寫）；在出版手法與目標讀者方面還滿像歐來禮的，如果你以為我在抨擊這種for-Dummies的書籍，錯了─我恨那些寫的差勁又孤芳自賞做作的書籍，根本沒把我當一般人嘛，我一直希望歐來禮可以為電腦科學領域出版。
不論如何，正規表達式(regular expressions)是一種迷你語言(mini-language)，用來產生與配對正規語言(regular languages)，這樣的概念是知名的語言學家Noam Chomsky提出的。一個"迷你語言"是一種特殊用途的語言，有著自有的詞彙與文法結構，舉個出名的例子，星巴克咖啡行話，這可是一種跟涂林機有著相同能力用來點咖啡的迷你語言，特色是豐富且形式自由的語法以及專屬的語彙術語，可組成符合格式的表達式，例如：大杯1/4份加奶泡到滿，一半咖啡因正常一半低咖啡因，牛奶一半低脂，一半脫脂，加熱到190度，無糖，半熟香草，半份白巧克力，半份正常巧克力摩卡瓦倫西瓦加一注無糖榛果以及一枝肉豆蔻香料，喔，還要冰唷。）
譯註：原文是："Grande quad-shot no-room light-foam half-caf half-decaf half-lowfat half-nonfat 190-degree sugar-free vanilla medium-roast half-white chocolate half-regular chocolate Mocha Valencia with 1 pump sugar-free hazelnut and a sprig of nutmeg. Oh, and make that iced."，我不懂咖啡，亂翻請包涵。
根據一名星巴克員工指出："字越多錢越多"，我想上述的飲品應該超過17美元，你需要針對每一個迷你語言學習各種慣用語以及效率考量重點，才能最佳化效能表現。
其他廣泛使用的迷你語言還有：訂披薩的語言（有很多方言，但大致上是通用的），醉酒水手罵髒話（在你收到以"修車廠與詐騙術的迷你語言"所寫的修車帳單時特別有用），當然還有，拉丁死豬文，在談到動作慢吞吞的同事時那可有用的很（"ob-Bay's ot-nay oo-tay ight-bray, is he?"）。迷你語言無處不在，且可以搞的相當有趣。
譯註："ob-Bay's..."，我看不懂。
正規表達式(regular expressions)也不例外，它讓你解析一份記錄檔的速度快過你說："Python用來不區分大小寫的metacharacter涵蓋整個表達式，還是只有在Perl如此？"就好像printf的格式字串的語法，不論你使用的語言為何，regexps(regular expressions)是個實用的工具。
強烈推薦。喔，我點的要冰唷。
#6) The Algorithm Design Manual, by Steven Skiena.
這本書是我一個朋友高度推薦的，他是個閱讀量很大的人（也是很厲害的程式高手）─事實上，在去年十月我在做民意調查時，他就是唯一（二十個中）讀過Refactoring的那位。
書的大部分我都讀過了，但我不確定是否每頁都看過，因為這本比較像是百科全書，而比較不像是一般連續敘述形式的教科書，我花了一點時間才開始體會到這本書是多麼好用，原因是我沒抓到這本書的整體架構，一部分是是敘述形式，一部分像是食譜，一部分又像是參考書目形式。
聽來很怪但真有用！幾乎所有常用的資料結構與演算法這本書很完整的都涵蓋了，但書的焦點集中在教你如何找出手上的問題的模型，挑選正確的演算法。書中滿滿都是經驗故事與真實生活中的案例。
大部分的範例都是wgah'nagl的，需要數頁的篇幅才能說的清楚，通常帶有詳細的圖解，如果你仔細地做過，就可以熟悉解NP-complete問題的有用技巧；我在這必須招供一下，在讀這本書之前我並不認為圖形問題(graphing problems)有多麼普遍，並不認為很多問題都可以用圖形演算法(graph algorithms)來塑模（以及解決），我錯了。
我過去讀過的資料結構與演算法的書籍有一拖拉庫之多，但從沒像這本的，這本內容採用了非傳統式的組織架構，令人耳目一新讓你感到有趣，我常常回頭參閱本書，而且每次都學到新東西。
結論，這本書一定要擁有。
#7) The C Programming Language, Second Edition, by Brian Kernighan and Dennis Ritchie.
這是本小巧又奇特的書，常常錯被用來當學習程式設計的入門書，可想而知一定會產生挫敗感，用這本來學習如何寫程式是不對的；本書預先假定你已經熟悉計算機架構、組合語言、編譯器，以及最少一個以上的高階語言。
甚至拿這本來學C也不恰當，C的一些習慣用法與良好的慣例常規已經有相當程度上的變更，即使你是從第二版出版的時間開始算，而且書中的範例看起來有點過時了。
不過，即便如此，這本小巧玲瓏的書仍然令人感到驚奇，C語言在效率與表達豐富性之間很明顯地取得了漂亮的平衡，就今日的標準看來，C看起來特色不多，而且很多人用C寫程式時會覺得很麻煩，或許是如此吧，我認為還要考慮到你所開發的軟體大小，以及對所用的語言與工具的熟悉程度。
C真的不適合用來建造巨型的軟體系統，其實從一開始它就沒被打算這樣用，為了Unix所以有了C，而Unix不是個大型系統；它是個巨大集合，包含了很多互相幫忙彼此合作的小系統。
C是個優雅的語言，對跟C++抗戰許久的人來說，就我看來C就像是股乾淨新鮮的空氣，試著用C++來打造巨大粗野的系統的人結果往往自己變成巨大粗野的程式員。如果你正要用C來寫大型系統，你最終會要從兩條路選一條走：
- 採用AlternateHardAndSoftLayers這個設計模式，大部分的程式碼用高階語言來寫，把跟效能有決定性關聯的部分用C來做最佳化。
- 試著把C提升到高階語言的層級，結果咧，不是瘋了去用C++，就是瘋了在沒有任何的語法支援下自己用C來打造高階語言。
Java可以說是把選項一好好包裝後的整套解決方案；是故，有整套方案的好與壞，好處是簡單，只要學一種語言，你就可以避免掉大部分低階語言的繁雜以及移植的困難，缺點是你並不是在用一套真正的高階語言，而且也不是那麼容易可以去最佳化跟效能有決定性關聯的部分，但總體來講，還是比選項二來的好。
當只論語言本身時，C是個美麗小巧的語言，今日很多（大部分？）的電腦遊戲都採用AlternateHardAndSoftLayers模式；遊戲引擎用C來寫，遊戲部分用較高階的語言來寫，而遊戲界可是在軟體工業中最在乎效能的世界之一，所以這算是給想用此模式的人一個很強大的支持點。
我想我上面要表達的是寫C是讓人心情愉快的，只要別想自己一人去寫野心太大的東西，而讀這本K&R書可能是將這點看清楚的最佳方式，如果你已經離開C一段時間，那讀這本絕對會有被C所懷抱的感覺。
結論：在與C++奮力抗戰一整天後，能夠回頭搞搞簡單優雅的事物是滿享受的。
#8) The Little Schemer, by Daniel P. Friedman and Matthias Felleisen
在你會遇到的最奇特神祕的技術性書籍裡面，這本毫無疑問是其中之一，但不要排斥其內容的編排方式，嗯，你一定會排斥，但試著不要未審先判，還沒讀就放棄。
這本書能夠排進我十大好書清單的原因是，在幫助我了解遞迴(recursion)以及以遞迴方式來思考的所有著作中，這本用的教學法最棒；Scheme語言在這方面是個不錯的選擇，雖然作者們也可以很輕鬆的用Haskell或Ruby達到同樣效果。說是這樣說，但那無關緊要，重點是觀念，比選用什麼語言更重要。
很多人很單純地跳過遞迴(recursion)，因為聽說遞迴的效能很差，他們沒做過實驗測試來證實，所以當遇到狀況，而遞迴是最自然的解法時，他們就有了大大的問題。
很多演算法用遞迴表現出來最自然，包括樹(tree)與圖形(graph)的traversals，線性與動態編程(linear and dynamic programming)，電腦語言與自然語言的語法解析，還有其他很多很多，如果你不習慣遞迴式的思考方式，你就會傾向避開遞迴式的解法，結果就是，碰到很多問題你寫的程式就會很醜且漏洞百出，其實可以不用這樣的。
The Little Schemer不是那種你可以坐下來像讀本小說一樣，或是像看一份J2EE技術手冊一樣來讀的那種書，你必須親自做過所有的範例，用手而不是光想，按照順序而且不能跳過任何一個。
比較痛苦的方式（個人意見）是使用Scheme的直譯器(interpreter)，我發現把範例改寫成Emacs-Lisp然後在emcas的lisp-interaction-mode中去跑還比較容易，只有幾點改寫的規則需要記得；或是你可以找到一個掛在你的編輯器上的Scheme外掛(plug-in)。不論你怎麼搞，你就是要動手去做──你必須親自解決書中的問題。
作者建議我們不要一次就想攻讀完整本書；大約有十章，我一天做兩章左右，所以我大概花了一禮拜讀完（每天大概一小時）。
攻克到書的一半左右時，你會真的開始體會其精髓，在那之後，大部分的內容作者都用來教你遞迴(recursion)的一些常見的慣用法，如果你真的有實際做範例，逐漸地你會發現，將問題表示成單一或雙重的遞迴函式就變得非常直覺了。
我還沒前進到Season Schemer──這本肯定會在我的"十大挑戰"中，十本我想要讀的書，不過我很期待那本。
結論：非比尋常的一本書，絕對夠格在我的十大好書佔據一席之地。
#9) Compilers, by Aho, Sethi and Ullman
這本是很（不）有名的"龍書"，到目前為止是最難的一本，甚至可說比The Algorithm Design Manual還難，因為這本的內容極端扎實，如果不是的話那就是因為我這個人很極端扎實，或者兩者皆是。
話說回來，其他我至今讀過的編譯器教材，沒一本讓我滿意，我在學校時用的是這本，我恨死了，每過幾年我就會拿出來，試看看能不能寒窗苦讀而後貫通，不過不用幾秒它就送我去見周公了，每次喔。超強的安眠藥，推薦給偶爾有失眠症狀的人。作者後來出用C寫的新版（舊的用Ada），或許比較好讀吧，不過我沒看過。
在跟Fisher and LeBlanc的大作奮戰了好幾年後，我終於買了一本龍書，想想看，我都聽那些毛骨悚然的故事這麼多年了，所以你可以想像這舉動不過是自暴自棄而已，可是大出我意外之外，我發現這本書真是讚啊。
那些導致說這不是一本適合大學生的好課本的論點我都可以接受，可是並非這本書的目標啊，龍書很明顯地是寫給想要好好寫一支編譯器的研究員或是專家們，書中差不多涵蓋了所有出版當時寫編譯器會碰到的問題，除了一些很先進的最佳化(optimization)技巧。我敢肯定Richard Stallman桌上擺了快翻爛的一本，還有過去二十年來所有可當做產品來賣的編譯器其團隊一定也都有。
我將在一份還沒發表的論文中主張編譯器(Compilers)與作業系統(Operating Systems)是電腦科學大學學位最重要的兩個課程，而且兩科目都應該是必修，不修不能畢業，遺憾的是，我還沒看過哪個校系把兩門列為必修，通常是讓學生只需要修一科（或兩科都不用）。
在這裡我就簡單說吧，知道怎麼寫一套編譯器以及了解它的架構，這樣的知識就是區分良好跟普通的程式員的關鍵，而且在所有偉大的程式設計師身上你可發現他們都是精通編譯器知識的，即使你從來不打算寫一個或是修改一個編譯器，這科目仍然是最重要的CS課程；而大部分學校居然沒告訴你這點是多麼重要以及為什麼重要，真是混蛋啊。
還有很多其他講編譯器的書，你大概需要跟很多本奮鬥過後，整個觀念與雛形才開始明顯起來，人類有辦法寫出來的軟體當中，最複雜的，編譯器當居其一，而且花了這個世界五十年的時間才能對它有到今天這個地步的了解──長遠看來仍不夠，不過情況慢慢改善中。
但是我認為一旦你真的開始對編譯器有所領會，龍書將是你會不斷回頭翻閱的那一本，所以放它在清單上。
#10) WikiWikiWeb, by Ward Cunningham and thousands of others.
我開始對從書架上找好書感到厭煩了，大部分的書不是 (a)很重要，但我還沒讀完因為我遜，就是 (b)不算太好的書。扣掉教科書外，我只有少數幾本書是能夠推薦給所有的程式員的，而且我已經在清單上放上兩或三本像磚頭般重的書了。
WikiWikiWeb （不知為何也叫Portland Patterns Repository）是世界上第一且最老的維基(Wiki)，雖然滿大的，但跟維基百科(Wikipedia)比起來就好像花生般不起眼，維基百科有將近400,000超高品質的文章與三篇爛的，它的姊妹們（WikiDictionary等等）也不容小覷，Wikimedia Foundation正急速地變成網際網路上最重要的智慧知識中心，儘管創立者的名字叫做金寶(Jimbo)。
不過WikiWikiWeb還是很酷，特別是因為有很多聰明的傢伙在上面對一些困難的議題絞盡腦汁做討論，Strong typing or weak typing？OOP, functional style, both, or neither？Pair programming or no？這網站上有著很棒的解釋文章與有趣的討論串，數以千計，這是少數讓我流連忘返的網站之一，在我程式員的生涯中這網站就跟我讀過的書一樣有價值，所以值得被列上清單中。
收場掰
今晚的上等優質紅酒我似乎喝多了一點點，而且已經開始自創像是收場掰這種新字了，所以該是時候做個結尾說再見了。
人客擱再來唷，下次的書單會更加有趣，將列出真的是石破天驚了不起至極的著作，我怎麼知道的呢？是因為我的確有讀了一章或半本，不過因太笨而沒辦法讀完，或是，我剛剛才發現，而且正想辦法看完。
很喜歡聽到回應，或是告訴我哪裡有其他人的愛書清單，我一直都是洗耳恭聽大家的推薦書籍。
（發表於2004年11月18日）
註釋
[1] 我現在Google工作，希望他們了解我當時只是開開玩笑罷了，別太認真啊。
No comments:
Post a Comment