文章：Ten Challenges 十大挑戰
日期：2005.01.23
作者：Steve Yegge
作者的部落格（2006至今）：Stevey's Blog Rants
作者舊的文章（2004與2005）：Stevey's Drunken Blog Rants
這篇文章很久了，不過我很喜歡看這種別人列出來的書單，總覺得透過這個可以了解寫的人的背景。還有，原文後有一些作者同事的回應，我就沒翻譯了。
注意，作者寫這篇時任職於Amazon。這裡有作者的背景簡介。
十大挑戰
不久前我推薦了十本書，對程式員來說是相當好/不可或缺的讀物，全都是相當基礎的內容；唯一有點挑戰性的是The Algorithm Design Manual，而且那本也不差。
我想應該談談其他我還在研讀（某幾本要用奮鬥這個字眼）的書籍，這些書大部分我都還沒看完，但全部都是極優秀的著作。
這些是對我很重要的書，不是像Lewis Carroll或Herman Melville那種重要；這些不是那種我很珍愛的小說，更不是那種厚到可以墊在沙發下的大部頭小說，大體而言，都是技術性的書籍，但每本我都是會定期回頭翻閱每當我想要理解──嗯，這世界是怎麼“運行”的。
顯然會超過十本，但我決定削減清單到十本，這樣才有機會在年底前寫完這篇。（注意：現在已是2005年1月22日，所以沒成功。不過咧，差不多了啦！）
廢話就不多說了…
#1: Gödel, Escher, Bach: An Eternal Golden Braid — Douglas R. Hofstadter
這是有史以來被書寫出來的書籍中，最美麗的著作之一，而且排在我書單最上頭，本書名聲高到難以置信，而且出版那年得了普立茲獎(Pulitzer Prize)，雖如此，那不該是你想讀它的原因，這本書是藝術傑作，寫給眾人的書，特別是像你我一樣的程式員。（如果你不是程式員，記得看看書單的第十本。）
關於本書有個趣聞，沒有幾個人曾經看完它，別會錯意了：他們都想讀完而且也努力試了，但根據你對於會使頭腦打結之遞迴式矛盾悖論的容忍力有多高，你可能會在三分之一到半路的地方就舉手投降了，我之前就這樣，後來我終於在放假時設法讀到2/3的地方，然後就一直在心理期待著哪天會看完…，所以我想情況還是沒什麼變，我的狀態還是在未完中。
甚至我一些大學教授也不能整本讀完，事實上，我只認識一個人有辦法，他在Amazon工作，不是你心理想的那個人（你大概根本不知道這個人），是個聰明的傢伙，其實在以前研究所編譯器(compilers)上課時，他就是那種當別人使出吃奶力氣忙著寫編譯器的frontend時，他卻已在寫backend的部份了，相當高竿。
我愛這本書，大家都愛，只是沒能力讀完罷了！內容太多太豐富，就好像試著吃掉像小卡車一般大且快融化掉的巧克力乳製蛋糕，我曾經在電視上看過吃冰淇淋的比賽，參賽者一直吃，吃吃吃直到抱著水桶嘔叫，感覺上不能說跟讀這本書的情況不像啊，而且你可以看到過沒多久參賽者眼睛又飄向冰淇淋，想著：「我看還可以再試一次，羅馬不是一天造成的，不是嗎？」
這純粹就是一本天才結晶，而且附著一堆樂趣，不只是因為這是探討智慧（不論是人類的還是人工智慧）的書籍中最好的一本，而且，這本書自己本身呈現出一首自我參照(self-referential)的賦格曲(fugue)，居然用書的結構做了一個雙關語向Lewis Carroll致敬。這本書定義了什麼叫做敘述形容，什麼才叫做描寫說明，你就是非得讀一讀不可，即使只到三分之一也好。
我覺得我好像越來越能夠描述出森林的樣子卻又沒進去森林中過，如果你懂我在說什麼的話。
#2: Structure and Interpretation of Computer Programs — Harold Abelson, Gerald Sussman
這本，通常用頭字語(SICP)稱呼它，在我清單上佔據了二當家的地位。謝謝 Andrew W在我的十大好書回應時提及這本好書。
看了Andrew的推薦之後，我馬上開始狼吞虎嚥這本書起來，就好像看到魔幻般的糖霜橡皮糖一樣，欲罷不能；我之前就買了也試著讀它，可是不幸的是，遇到浮誇炫耀與差勁的笑話組合後就看不下去了，好像看到一個高高在上自負的教授，自以為夠了解流行，編出一些小x或林痣玲的故事，我真的消化不了。
譯註：原文是“Imagine a really arrogant, condescending professor who thinks he's hip, and he makes up stories about students named Louis Reasoner or Ima Pseudonym or whatever”.
不過一旦你能抓到那種調調，它就是一本偉大的書，有多偉大呢，就好像：「很多學校因它而改變了教授電腦科學的方法。」那種偉大，在麻省理工學院(MIT)用這本當做程式設計入門課程的課本，還有（我印象中）柏克萊(Berkeley)，應該還有其他學校。
我很清楚記得那年，喔，是這個年份嗎，1998年？那年我聽說華盛頓大學(University of Washington)要再次更改程式設計入門課程，轉而改用Java，他們領悟到Ada不再是最尖端的程式語言了，巴貝奇(Babbage)都仙逝超過一世紀了。（事實上，Ada *曾經*很酷過，不過千萬別說我說過這話。）
無論如何，我記得有聽說華大的CS入門課程候選語言之一是Lisp，“Ｌｉｓｐ！！？？”我頭上出現三條線，不管言語上或肢體上我當時可能都被這樣的計畫搞到義憤填膺，見鬼了，他們用Lisp教新手是想幹嘛啊？
現在我知道這問題的答案了，但我基本上還是反對，任何學校，包括MIT，我都反對在CS入門課程時就使用Lisp教學；所有我面試過有修這種課且辛苦挨過的人，從沒明白為什麼當時搞什麼鬼要學這麼難懂隱晦的語言，新的CS學生就是還太嫩不能接受Lisp。
大部分的人永遠沒辦法接受Lisp，就好像他們沒辦法接受數學，或是哲學，或是當我們把我們自己毀滅掉以後，任何其他會被外星人異形記住與保存的人類遺產；不過有時候我會想知道：如果歐來禮(O'Reilly)出了一本“Lisp Cookbook”，封面上畫著某種巨大醜陋的怪物（我希望是喜瑪拉雅上的雪人，或是翼手龍），會有多少人開始認真看到Lisp？
這本書不是歐來禮，它是MIT Press出版的，就好像這份書單中其他本一樣，所以它是只寫給聰明的人看的，ㄟ，就這本書而言，意思是，不介意被作者屈尊就教的聰明人。
這本書涵蓋了…嗯，什麼都有，就如同Gödel, Escher, Bach一般。我終於學會Huffman encoding是怎麼運作的（相當酷！），還有Scheme的超環形直譯器(metacircular interpreter)真是難以任人置信啊，書中介紹的picture language只能用美來形容，即便MIT創辦人看起來不美。書中塞進的範例程式，如果用Java或C++寫如果不花上數百頁也要花上數百行，用Scheme寫通通只需少許的程式碼就夠了。
絕對算是我的愛書之一，或許不適合給程式員新手，不過你如果對我和冷涼卡好的豬哥亮這類人有共鳴的話（“毋關乎你在身分證上的年齡，事關乎你對幽默感的感受力”），那我想你會沈醉在這本書之中。
譯註：原文是：“but if you're more like me and Montgomery Burns ("It's not how old you are on parchment, it's how you feel in the humours!")”。
#3: Digital Typography — Donald Knuth
這是本Knuth寫的書，對大部分的程式員來說，那表示：「每個人都在吹捧誇獎這個電腦科學界的老傢伙寫的書，可是沒人真的會去翻
Donald Knuth，事實上，是電腦科學界中最好的作者之一，他很有趣，好吧，或許只有我這麼想，或許當看到一個數學家笑話時其他人都作嘔嘆氣而只有我會笑出來，但我真的從他的書得到些什麼，每當我閱讀Knuth的著作時，我知道我會被妥善對待。
如果你們之中有人需要招募或面試新人的話，看看他了履歷表，或稱為Curriculum Vitae，就放在他在史丹佛(Stanford)的網頁上，我覺得Knuth把他的履歷放在網路上真的相當搞笑，我可以想像得出來面試過程會像這樣：
Donald: 嗨，我是Donald Knuth，不知道你是不是有任何的職缺─
Stevey: 啊啊啊～哎呀！！！〈昏厥〉
Donald: 你不是要問我一些專業技術問題嗎？
Donald是最強的，某天某人說他們覺得他有點兒傲慢自大，這個嘛，(a) 我自己是從沒有過這種感覺啦，雖然我一直沒能讀完他的The Art of Computer Programming（聖誕節我收了這套書兩次，如果你相信的話。怎麼大家都猜透我了啊！）還有(b) 不管怎麼說，我認為Donald有資格自負，當你把印刷業踹進淘汰的角落時，你就贏得了那種資格，實至名歸，你甚至可以穿著T恤上面寫著：「我就是Donald Knuth而你不是」。規則就是如此。
那，這本書有什麼特別之處嗎？他可是發表了一卡車的著作，我老實告訴你吧：我選這本書的理由，有部分是因為這是我勉強算是讀完的唯一一本；不過一直以來我慢慢地研讀了他的不少書籍，而這本相當特別，非常非常特別。
其一，此書自我參照(self-referential)的形式，其運用方式是連Hofstadter也極少用過的，它不斷地參照它自己的版面編排，而且這是本美麗的書，畢竟，它整個都是用Knuth自己的TeX軟體，什麼是TeX呢？，就是這東西的純文字音譯，TEX：Donald的軟體（用Pascal寫的，信不信由你），用來作數位排版(typesetting)，讓你指定你想印的東西該如何描繪編排於印刷頁面上，不論是印在網路上或紙上。
其二，這本書，嗯，有魅力。當初Donald是寫給1970年代的讀者群，正負十年，至少在當時這樣的書可說是石破天驚。你要心存感激啊，當他出版The Art of Computer Programming前兩冊時，當時他必須操作一種巨大+水銀蒸汽+金屬的醜惡怪物，一種可能更適合待在史蒂芬金(Stephen King)小說中的怪物，就為了把稿件以書籍的形式印刷出來。
Donald心想：「我是個數學家又是個程式員，而字型(fonts)與排版(typesetting)似乎是有演算法可依循的(algorithmically tractable)，就讓我試試是否能寫個軟體把印刷業取代掉吧」，他試了，而且成功了──雖然比他當初所預期的多花了十倍時間，就如同所有超棒的軟體一樣。
Digital Typography是部橫跨整段旅程的的論文集，從作者意識到其實可以用電腦來控制字型與排版，到最近版本的TEX為止，這套軟體依然是世界上數一數二的排版系統，附帶一提，TEX目前到了3.14159版，從第3版開始，他們改了版本號碼，每發行一個新版就增加一個 π 的數字；多年來，Donald提供一筆小獎金給任何找出TEX臭蟲的人，他甚至把支票寄給你，雖然很少會被拿去兌現，因為把一張因找到TEX臭蟲而由Knuth開出的支票當做收藏的話其品價值更高。
注意到前面那一段的編排是怎麼被TEX的標籤搞得很難看嗎，因為我把'E'改成下標做做樣子，當然，真正的TEX就沒有那樣的問題，瀏覽器真是遜啊，不是嗎？嗯嗯嗯…或許Microsoft跟Mozilla都應該努力追趕1970年代早期的排版與描繪技術，是嗎？
不論如何，即使你對排版沒興趣，都應該讀讀這本書，你會對一些已經習以為常的事情重新給予評價，而且閱讀此書本身就有樂趣，高度推薦此書，作者其他所有的書也是。
#4: Programming Language Pragmatics — Michael Scott
我認為這本書(PLP)是你可以找得到的關於程式語言的最佳入門書，這本“有點兒”在討論語言設計(language-design)，“有點兒”在講編譯器，“有點兒”在講很多很多東西；此書包含了數十種的語言，以非常務實的角度，討論語言設計者下了什麼樣的選擇與其trade-offs，書中從不宣稱哪一個語言比哪一個“優秀”，相當不錯的一點，它只是告訴你這些語言中哪些部分簡單哪些部分困難。
這本書大致上以編譯器(compilers)教科書的方式排列章節，從tokenizing開始，到syntactic analysis，然後semantic analysis、runtime organization、code generation、以及（一些）optimization，讀這本可以詳細了解編譯器的運作模式，而又不必真的寫出一個。（注意：什麼都不能取代真的動手寫一個，最好的第二種方法就是看這本書囉。）
不像大部分的編譯器教材，在討論如何設計一個語言時，PLP很多篇幅都在講為什麼你會如此作設計、為什麼你可能那麼抉擇，很多技術文件（有跟寫程式沾上邊的）的都有個大問題，給了一長串的選項，可是卻沒給你任何的選擇方針；這本書講求的是實用主義，作者覺得這跟syntax與semantics一樣重要，都是學習設計語言時的核心設計原則；這是本非常注重實效的書。
寫的非常好，非常非常非常好，不像書單中的其他本，這本書非常樸實而且是寫給像你我般的凡人看的，整本書的組織架構很清楚，處處都有索引與交互參考，很容易地可以跳來跳去，我發現我自己用一種非線性的方式在讀這本書，順著書中的關連性從這小節跳到那小節，書中有一堆精心製作且幫助極大的圖表，每章後的練習題，還有不計其數的參考文獻。
此書基本上涵蓋了所有你在近代程式語言中可以找到的功能特色，所以讀此書會讓你更容易地學會一個新語言，因為你已經熟悉了最尖端的概念，譬如pattern mathing、lazy evaluation、parametric polymorphism、multi-methods等等，還有，你會知道這些是怎麼被實作出來的，所以你能夠比較出它們相互間的效能差異。
好書一本，優點實在說不完，你可以在Amazon上看到一些篇幅，我鼓勵你去看看版面編排與寫作風格，你會發現這本書很易讀，我這本已經快翻爛囉。
#5: The Essentials of Programming Languages — Friedman, Wand, Haynes.
我剛剛從Amazon收到這本書，MIT Press出版，當然啦，清單中有很多本也是一樣。
Daniel Friedman和Matthew Felliesen是我心中的兩個英雄，不，我從沒遇過他們，就好像我認識Heracles或Kurt Vonnegut Jr.但他們不知道我一樣，話雖如此，他們兩位還是英雄，他們兩人任一位寫過的著作，幾乎都是我想要──嗯，刻在青銅器上，我猜；或是蝕鏤在石頭上，不論什麼方法，反正就是讓一本書能夠流芳百世就對了。
雖然不被我們的顧客評論所了解肯定，但這本書真的是個大寶藏，我會無視大部分的評論。（除非你認為“witchkingofangmar”是個可信的評論家，天啊。）
這本書建構出幾乎所有你需要用來了解程式語言的基礎概念（容我插一句，這是件好事，如果你用得到全部的概念的話），以漸趨複雜（但從不會過度艱難）的Scheme直譯器實作出這些觀念。
我是在偶然的情況下撞見此書，在一份解說如何把list comprehension轉成一連串的map跟filter敘述的演算法論文的參考文獻中看到的，List comprehension，以及map、filter跟其他親戚們，真真正是超有用的抽象概念(abstractions)，絕對值得你花時間搞懂，包括它們是如何在編譯器或執行階段實作出來的。
今早面試時，一個應徵者實際地解釋給我聽為什麼他認為這些概念很有用，他指出（我認為是正確的）當你在某個特殊的商業問題中打轉時，你不會還想去操心迴圈計數器是否該從零開始、該在最後的索引值還是要減一前停下來；你想作的就是給一份清單在每個物品上執行某個動作（例如取出售價、商品的資料，什麼都好），而Map恰恰好就是如此這般。
List comprehensions在比Map高一點點的層級上運作，它們幾乎就像是一種用於你的資料結構的探詢語言(query language)（以SQL或XPath那種觀念來看）。非常有用，你說出想要找什麼，找到後也可以執行某些運算，得出答案，而且這些動作“如魔法般地”就在檯面下完成了，嗯，我會希望這不是像魔術一樣：除非你或多或少懂得一個抽象概念(abstraction)是如何被實作出來的，要不然不該使用它，否則你會很容易地遇到效能問題，而且不知道怎麼解決。
那就是這本書的價值所在，它的角色跟Programming Language Pragmatics很類似，但取向很不一樣，PLP的內容更廣泛一點，但看來好像有一點令人怯步，相比之下這本書的內容把重要的常見語言特色挑出來，證明給你看實作這些概念是多麼容易，至少用Scheme實作是如此。我認為可以跟演算法玩玩而又不用擔心迴圈計數器是很棒的學習方式。
我不會推薦這本書，除非你已經很熟悉Lisp或Scheme，這是本相當高階的教科書。
#6: Types and Programming Languages, Benjamin C. Pierce
我的工作團隊中，有個傢伙在華盛頓大學某堂CS課程，他真的用這本書當做輔助教材。這實在酷到我沒辦法跟你形容。
好啦，其實我可以：這真的很酷，他是個聰明的傢伙，差不多就是跟我之前提過的那個寫編譯器backend的聰明傢伙同等級，而且當他“只不過”是我們在大學的室友時就已經讀完Gödel, Escher, Bach，這傢伙聰明到會引起驚慌，諸如，我通宵達旦地學習研究就是怕他有一天會問我某個複雜難懂到可怕的程式難題，不過他不知道這件事，別跟他說否則那念頭可能會鑽進他的腦袋，而他將會想成為一名“架構師(architect)”，然後我們就再也看不到他在作事了。
這是書單上最難的一本書，到目前為止也是我進度最少的一本，不過，這是最重要的其中一本，會這麼重要是因為型別系統(type systems)是程式語言不可或缺的關鍵所在──設計的方式與使用的方式，本書討論各種重要的包括C++與Java的型別系統，以及從這些系統可以預期得到的衍生問題與保證帶有的特色。
書中花了很多時間來講ML type system，這是型別檢查最嚴格以及最“優美”的型別系統之一，討論它的書會越來越多，而且越來越多的語言開始使用它，它被認為是世界上最優秀的型別系統之一，因為它給了你很大的彈性還有能跟Perl相比肩的表達豐富性，同時間維持住編譯期間的型別嚴格檢查要求，致使你不會把資料放進型別錯誤的地方，這基本上可說是strong-typing跟dynamic-typing兩個世界最佳的組合，因為大部分的型別標籤(type tags)你都毋需宣告了。
有趣的是，型別(types)這東西，大部分的程式員沒想過太多，有時候我會問來面試的人：「什麼是資料型別(data type)？」通常他們在能夠回答出一個差不多像個樣子的答案前，即使是錯誤的，都要花上個半天；很多人從沒思索過這點，最低限度是他們懂得夠多曉得他們不想要在定義中使用這個字眼“type”（或同義字）。
當人們不知道如何跟我說明什麼是datatype時，我覺得很怪，因為將你的data types結構組織化是寫程式最基本的部份，它確定位於“物件導向設計(object-oriented design)”與設計模式(design patterns)的核心，你要設計怎麼樣的類別(classes)，類別間的關係又是如何怎麼互相溝通的？提供什麼方法與動作？存取控制又是怎麼安排？什麼樣的資料型別可以當做參數？你如何排列型別來通過線路傳輸？
這些問題都跟程式語言所用的型別系統緊密地綁在一起，你的選擇會影響軟體系統的所有性質：可讀性、易維護性、堅固性、執行期間的效能、靜態編譯需時、等等。
即使你不想追著書中的數學分析，一直略讀過去直到結論也是個好主意，換言之，了解在證明什麼比追著證明的過程要重要多了。
另外詳細討論資料型別(data types)的地方是Programming Language Pragmatics的第七章，PLP的說明方式就很不數學，而且，嗯，很務實，可想而知吧。你可以從那本開始然後到這本，如果想要學的更細的話。
雖然此書用了相當一板一眼的方式來寫，還是本容易讀懂的書，值得一看。
#7: The Seasoned Schemer — Daniel P. Friedman, Matthias Felleisen
The Seasoned Schemer是前傳The Little Schemer的繼承之作（當然囉），而且本書也在封面以及每章開頭畫上了開心的大象。
作者們有出另一本書，是一本令人發笑的書，同樣也是以問答的方式呈現，叫做A Little Java, A Few Patterns，我書架上就有一本，雖然你看不到但上面放的都是我真的在乎的書。
那本“Little Java”會讓人想笑，是因為它介紹跟The Little Schemer與The Little MLer完全相同的程式設計觀念與抽象概念，但居然想用Java來寫，其風趣的程度與Ken Thompson的涂林獎演說大致雷同，他演說時提到他辦的Quine競賽：“會有人拿FORTRAN語言來用，原因就跟兩人三腳比賽會流行一樣。”（順帶一題，這是篇好演講。）
如果跳過The Little Schemer最後一章沒看的話，The Seasoned Schemer對你來說就會像一隻真的熊，很難殺死，我之前就是這樣，以至於必須回頭仔細研讀一番，這本書立基於之前導出的Y-combinator，一個自我產出遞迴(bootstraps recursion)的重要函式。
此書取了個恰當的書名，真是本難以攻克的一本書，但辛苦留下的汗水是值得的。底下當我談第八本書時，我還會再多說一點為什麼你會動念頭想花那個心力去研讀。
#8: The Scheme Programming Language — R. Kent Dybvig
沒錯，又一本Lisp相關的著作，也是一本MIT Press出的書籍──橫掃了今天這份書單，超過一半了吧。我把這本放上書單的原因是，跟之前一樣，我還沒能讀完但又常常拿出來翻閱，而且對平常都在用的：C、Java、Python、Ruby等等，此書讓我對這些語言有了某種更深刻的理解。
我相信很多人正露出冷眼不屑的表情，因為我們知道Lisp沒什麼實用價值，如果Tim O'Reilly都還沒出版Lisp的書，那它一定是不實用的，還有，記錄上，MIT畢業生會被我們的面試刷掉，因為他們通常不夠了解C++。（最後這段話讓我苦痛煩惱到不行，你是無法想像的。）那麼為什麼我一直把重心放在Lisp相關書籍呢？
Scheme(小巧且純粹的Lisp分支）會在電腦科學課程中得到這麼大的注意力，不是因為它是個小巧到不行的語言，而是它將一股巨大的能量包裝了起來。非常易學的語言──很多教授說他們可以用一堂課就教完Scheme的基本用法，而且學生能夠馬上開始用它來寫程式，而且它也是非常容易實作出來的語言。
那是很重要的一點，當然啦，學C也算是容易，但寫一支C編譯器(compiler)就是樁複雜的功夫了，寫一支C++編譯器可說是難以置信地困難，至於寫Perl直譯器(interpreter)根本就是不可能的任務，因為沒有規格文件(spec)可言，而且(C++也一樣)Perl語法基本上是無法解析的(un-parseable)。
不過在大學部程式語言課程中，學生常常把寫一支Scheme直譯器當做一個科研項目，而且相同的程式，用Scheme寫通常都比其他較複雜的語言來的短，為什麼我們要花這麼多心力來學在效能表現一樣的狀況下比較複雜卻較沒表達力的語言呢，我無法回答，或許都是因為那些嚇人的括號(parentheses)吧。
我剛說實作很容易，想要證據嗎？這裡有個例子，雖小但實實在在的Scheme直譯器，用Java寫的。（寫的人，Peter Norvig，至少出了一本人工智慧(Artificial Intelligence)的書，現在是Google的搜尋品質部經理(Director of Search Quality)。嘿！他們還有可能成功嗎？他可能根本不懂C++，他絕對沒法子通過Amazon嚴苛的雇用標準。）
在JScheme網頁上，Peter說他原本計畫花少於20小時來寫直譯器，包括學Java的時間在內，他說他成功了，看看程式碼（不多！），我是相信他的。
好吧你說，Scheme很小巧，直譯器很容易實作，比任何其他語言甚至是BASIC還容易，那麼，這有什麼大不了的，你說啊？
了不起的是，同樣複雜的程式，你用Scheme寫出來就是會比Java或C++寫的短上那麼一大截，Scheme或許小，但它提供的概念跟建構元素卻驚人地有威力，譬如說，SICP那本書，用一頁的程式碼就寫出完整的Huffman編碼與解碼實作，還有，Dyvbig這本書（現在正在介紹的書），也用Scheme寫出一些同樣驚人的程式，至少，用程式碼的大小來評斷是很驚人的。
程式碼壓縮(code compression)是個好事嗎？在讀了好幾篇Paul Graham的論文後，我得到一個這樣的印象，他覺得程式碼壓縮是與語言（以及程式）設計時的最終神聖目標，我不確定我是否完全同意他說的，因為，很明顯地達到某個程度時，可讀性就會反過來下降；其實，如果程式碼壓縮是最重要的評斷尺度的話，你或許可以乾脆去用gzip。不論如何，我把“paul graham compression”打進Google，得到這個連結，連結中說了一模一樣的話，他們同意有一種所謂的“語意上的最佳壓縮”，這是可以花時間研究的，而且絕對不是把程式碼用gzip壓縮一下。
從另一方面看來，我還是認為Scheme程式碼相當“稠密”（幾乎是不可讀的），寫很簡單，但讀一支程式就不能跟C++相比了，我不太確定有多少是因為我對語言的熟悉程度不夠高，又有多少是根植於語言本身的特性，例如，缺乏型別標籤(type tags)與interface signature，資料型別是有實際幫助的，而且Scheme沒有一套標準的方法可以像javadoc那樣子的文件自動產出工具。
嗯，我可以不斷跟你談Lisp的優缺好壞，一整天都沒問題，不過我確定你不會想聽，我不是主張你應該通通用Scheme來寫你的程式，或任何程式；Scheme或許在Free Software Foundation的 (也就是GNU)的新腳本語言(scripting language)，Guile Scheme，有一些實際用處，在那裡，你可以寫腳本給GNU軟體(gcc, gdb, emacs, gimp等等）作自動化，特別是當有越來越多的GNU軟體開始支援Guile後；但在廣闊的其他世界裡就沒那麼有用了。
就像我在開頭說的，這份清單上列的，不是那種，對你的日常程式員生活，會立即產生重要性與實用性的書。
別的不說，Scheme讓我對比較熱門的語言的運作有更深入的了解，例如Python、Ruby和Groovy都開始納入Lisp的特色功能（譬如說，first-class continuations、first-class closures、將來可能有macros），而且讓能你在比較複雜的語言中使用這些功能前，先在最簡單的Scheme環境中打好基本功。
很硬的一本書，所以別想要在一天內讀完。
#9: How to Design Programs — Felleisen, Findler, Flatt, Krishnamurthi
這是本了不起的書，如果你是個程序員，你絕對不該讀。
沒錯，不應該讀。
這本書是給非程序員的，如果你不是，而有想過走進程式設計的世界，這可能是條路，肯定不會輕鬆的那種路，但你將會從最純粹的形式來學程式設計，這本書是寫給還不知道怎麼寫程式的人看的。
程式員不應該看，因為他們通常可以分成兩類：
- 已經懂Lisp(或Scheme)的程式員，他們不需要這本書。
- 不懂Lisp(或Scheme)的程式員，他們不能理解這本書，因為他們認為學程式設計就是為了餬口飯吃而只需要知道一個語言就夠了。如果你已經是個程式員但不懂Lisp或Scheme，速速遠離此書。
這本書用了一個叫做Scheme的程式語言，是這個星球上最簡明最強有力的語言之一，用Scheme寫程式就好像是你可以使用優美的英語而其他朋友卻只能用單音節的詞彙講話（我說的是Java或Perl或是C++），當然啦，很多有用的單字只有一個音節，一些特別有用的字也只有四個字母長，所以當面對今日的難題時人們可以用Java/Perl/C++就足以回應，但想說的漂亮優美的話，你需要Scheme，或類似的語言。
這本書真的是以從沒寫過一行程式的人作為對象的，我懷疑這樣會有效果嗎？如果你不是程式員而且想試試看這本書，我會渴望著知道結果如何。書中友很多的說明敘述跟一點點的程式碼，作者非常用心地試著從基本開始解釋起，也假定你只懂一點點或根本不懂電腦。
但從另一個角度來看，當你在寫一本類似的書時，要回憶起當初什麼都不懂的光景是很困難的一件事，所以這種寫法或許是糟糕的，如果你是個在Amazon的人，想要試著學寫電腦程式，手上拿著這本書而不知道開頭或下一步該怎麼做，告訴我，我很樂意幫忙。
#10: Purely Functional Data Structures
這本書我還沒讀到多少，主要原因是我最近以來都淹沒在（*嚥了口氣*）這書單外的書籍中，那是我依賴手指頭作算數的結果，也是把清單限制在十本的原因。
情況是這樣的：關於這本書，讓我談談為什麼它會是我想讀的書而不是討論書籍本身。
過去幾年來JG和我兩個人，對於吾人在Amazon碰到的分散式計算難題，我們不斷地尋找而且越來越渴望有一個（非常）徹底的解答，我們每週至少討論一次，互相對照一下研究筆記。
到目前為止，研究結果顯示，所有愛用J2EE的人都應該被捆在火箭上轟隆隆地飛向太空，不過這只是初步調查成果，我們也還沒準備好發表。
JG和我相信在外面存在著解答，淹沒在一堆堆一批批的論文著作中，包括程式語言的、作業研究(operations research)的、分散式系統的以及其他領域的文獻，可惜的是，研究員很少有像我們這種巨型的系統可以用，所以他們的理論，在能被應用到我們的問題上之前，需要被篩選跟消化吸收，那是我們要下的功夫。
有一點我要說說，現實已經很明顯地告訴我們該是將抽象程度向上提昇的時候了，整個公司已經沒辦法有效率地應付我們那幾億行的程式碼，每當我們堆上由IDEs自動產出的OOP和設計模式的屎爛架構，這數字只會越來越大，我發誓這些Eclipse專家只能見樹不能不見林，每個人都想當架構師(architect)，對這個稱呼他們似乎覺得，就跟為每個需要執行的單獨運算生出幾百個檔案是相同的意思；我將為這點寫篇部落格，但我今天不能離題，這篇文章在硬碟放了已有數月之久了，我想要今天把它發表出去。
我們需要的抽象程度等級應該是在語言抽象化(language abstraction)這一層，我不知道是否應該在伺服器叢集與網路上加入Amazon特有的迷你語言(minilanguages)來處理pattern-matching，或是應該是像Erlang或Gambit Scheme那種完整成熟的網路語言(networking language)，但我知道的是，物件導向介面(Object-Oriented interfaces)在扯我們後腳，而且我們必須把今天的網路變成像一部電腦那樣，這樣我們就能開始直接在其上寫程式，猶如一台簡單的機器般。語言抽象化，加上有穩固的數學與理論基礎支著持，是唯一可停止程式碼繼續瘋狂成長的希望。
為避免這一切聽起來像是荒唐的叫囂，讓我指出一點，JG跟我還有其他大約18位的亞馬遜居民(Amazonians)，在這裡工作快接近第六年了，我們原先在一家叫做Geoworks的公司，花了五到十年的光陰，用80x86組合語言來撰寫整個作業系統跟應用軟體，每個人都覺得那是個好點子直到我們退出市場；程式員總是對於目前已經投資心力在其上的系統與程序有種情感連結，很容易就看出同樣的情況又再次出現，這次是在較高的抽象層級：EJB和C++專家們認為藉由他們別緻高級的OO interfaces，他們是在一種虛無飄渺的純粹思想世界中工作，事實上，他們做的事情跟組合語言的層級還比較相似。
你可以跟我爭辯，但你必須解釋為什麼我們系統的穩定性一直出現問題，我鼓勵你做個即席考察：問問經理們跟資深工程師們，為什麼我們的系統穩定性這麼差，我一年前做過，問了快要30個人，全部都回我相同的答案：複雜度(complexity)，我們的系統已經變得無法理喻般地複雜(intractably complex)。
我寫介紹John von Neumann的部落格的用意在於，他是那種遇見無法掌控的複雜度(intractably complex)時，會去找一套全新的理論模型來讓問題回到可掌控的複雜度的狀態的人，事實上，如同George Dyson在他最近的談話指出，von Neumann真的有發表過一套初階的理論，說明如何以不可信賴的元件建造出可信賴的系統，然後他開始研究cellular automata跟其他形式的平行系統，因為他知道這些系統將會是達到大規模運算的唯一途徑。
今天，由序列式電腦所組成的網路，我們卡在上面而且還不太了解，情急拼命地堆上更多的程式碼，冀望這樣就能不知其所然地修正一些東西；JG跟我相信我們會有一條路可走，就在平行運算(parallel computing)領域的某地方──所有的伺服器都成為平行節點，所以這並不算是思想上的大跳躍，我們一直都在調查相關的研究，所有可能的途徑都指向相同的一組結論，其中之一是說在新世界裡，Functional Programming是不可或缺的，這是個走在前端的結論。
也就是說，繞了一個圈子後，把我帶回到這本Chris Okasaki的書，這絕對是獨一無二的著作，這是世界上第一本討論purely functional data structures的教材──也就是，沒有邊際效應(side-effects)的資料結構(data structures)；我不打算在這篇部落格解釋為什麼對Amazon跟分散式運算來說，這是個重要的議題，我只會指給你這本書，希望你也有興趣找到解答。
收場白
這些書或許看起來很硬，但整麼勞心費力的目的是為了讓程式員能夠過得舒服一點，J2EE可以看起來是簡單的，C++可以看起來是，嗯，啊，呃，至少還算是可以掌握的；現在寫程式勉強還能算是有趣，而我們軟體系統發出的哀號聲，就看做是只能與之共存的自然之力吧──暴躁的異教神祇控制住我們的系統，而我們能做的就是奉獻上更多的程式碼。但誰說情節一定會如此發展，跟你今天用的陳年舊物相比，二十年後的程式語言想必會大大的不同（而且更加強大），說不定會讓人覺得今天的你好像在以組合語言寫程式，甚至更糟。
但答案在某處，而我們希望找到它，或者至少當其他人找到時我們也能察覺，然後我們就可以在這裡開始用。
（發表於2005年01月23日）
No comments:
Post a Comment