2009/08/26

讀後感想:龍紋身的女孩(The Girl with the Dragon Tattoo)與玩火的女孩(The Girl Who Played with Fire)

注意:會提到情節,小心踩雷。雖然很想寫出一篇好的讀後感,但斷斷續續寫了以下這些,有點零零散散,大家多包涵囉。

這是瑞典作家史迪格.拉森(Stieg Larsson)的「千禧」系列小說的前兩本,第三本的中文翻譯還沒出,聽說原本預計要寫十本,但作者因心臟病突發於2004年逝世,享年五十,真是天妒英才啊。

書名:龍紋身的女孩(The Girl with the Dragon Tattoo)
瑞典原名:Män som hatar kvinnor ("Men who hate women")
作者:Stieg Larsson
譯者:顏湘如
出版社:寂寞

書名:玩火的女孩(The Girl Who Played with Fire)
瑞典原名:Flickan som lekte med elden ("The girl who played with fire")
作者:Stieg Larsson
譯者:顏湘如
出版社:寂寞


會買來看的原因很簡單,第一,聽說賣的很好,第二,我認識一位瑞典朋友。其實理由二就足夠了,暢銷書那麼多,我也不知道怎麼選來看,像我買了暮光之城,嘿嘿,原本是有打算要看完整個系列的,不過看完第一本就晾在一旁了,裡面的男女主角扭捏作態,尤其是男主角個性太娘,讓我興致缺缺,雖然就描寫吸血鬼而言覺得是好書,但總感覺,嗯,是給青少年看的吧,我老了(成熟了?),讀了並沒有得到什麼樂趣。

以前看書時,對於故事發生地與其背景總是不太在意,我會想像那是發生在一個遙遠的地方,雖然是真實存在於地球上,但心理總想著,反正我又不會去那裡,哪裡都沒差啦;但看這兩本時不同,因為有個朋友住在那,因為我的確將來打算去那裡旅行,當看到書中的一個地名時,我都會想知道那是在哪裡,斯德哥爾摩(Stockholm)就不用說了,那是瑞典(Sweden)首都,有次看到Linköping時,心中想著,哇,這是她讀大學的地方耶。地名不再只是一連串符號組成的識別字,而變成有意義的聯想延伸點,那地方是在瑞典的哪裡,氣候怎樣,是不是終年冰雪,交通如何,有多少人居住呢,等等的問題就不斷浮現出來,不僅如此,書中援引很多瑞典的歷史與近況,例如龍紋身的女孩中的男主角卡爾‧布隆維斯特有個外號叫「小偵探」,原因是他曾經誤打誤撞破過一件案子,而且其姓名與《大偵探小卡萊》的主角少年偵探卡萊‧布隆維斯特極為雷同,而這本偵探書可不是捏造的,其作者Astrid Lindgren(1907-2002)是瑞典著名的兒童文學作家;還有,男主角在書中的職業,簡單講是一個財經爆料記者,專門報導公司財團的醜聞與不法行徑,書中穿插的政商背景皆有其人其事,書中提到的ASEA Brown Boveri、Wallenberg group、Kinnevik Group等等皆為實際存在的公司,另外提到一些軍購醜聞、首相被刺殺、瑞典納粹法西斯主義政黨等等,皆真有其事,還有其他很多很多,如果是以前,我看過便罷,但現在我至少會多注意一下,多看一眼,一切的一切都是因為我有個瑞典朋友!

第一本的原瑞典書名直接翻譯的話應該是「憎恨女人的男子」,不過中英文版都改做「龍紋身的女孩」,我想是因為,女主角莎蘭德太具特色了,是個極好的賣點;不過如果只看第一本的話,角色莎蘭德還不夠完整,也有個很明顯的“天大惡行”伏筆,看得出來作者預備在第二第三本繼續發展;第一本的重心是在男主角布隆維斯特身上,其生平與職業生涯,與女人的關係,立志作一個不吹捧商界明星的人,受到欺騙而陷入毀謗官司,等等,以及答應一位富商試著解開已沉寂三十幾年的懸案,最後引出憎恨女人的男子;而女主角莎蘭德雖然也得到不少篇幅來描寫,但相對於男主角的「正常」,女主角的經歷顯得太過奇特與離經叛道,兩人會在一起辦案以及女主角受男主角吸引的理由我個人覺得有一點點不能接受;不過還好,很多其他故事中的男女主角都是因為某種更講不通的原因而認識,甚至糊里糊塗地就走在一起了,我們就把這解釋成緣份吧。

龍紋身的女孩在結尾時,關於布隆維斯特與溫納斯壯的糾葛,因為布隆維斯特想要報導溫納斯壯的不法情事,但卻又證據不足,書中安排的情結讓我們以為當主角解決富商范耶爾的懸案後可以得到一些線索或證據,偏偏那是個范耶爾把布隆維斯特騙來辦事的幌子,於是乎,最後由莎蘭德發揮通天撤地的駭客本領,侵入溫納斯壯的電腦,裡面有著極為詳盡的犯罪資料,才讓布隆維斯特扳倒溫納斯壯,哇哩咧,未免太好康了吧,照作者這樣安排,莎蘭德就好像神一樣,看誰不爽那人就一定倒楣,不僅如此,書末安排讓莎蘭德將溫納斯壯暗藏的錢通通轉到她擁有的帳戶,從本來買台電腦還要請監護人同意的小女孩變成億萬富翁,而且當警方黑道都在追殺溫納斯壯卻找不到他時,還是靠莎蘭德打了支電話,然後,溫納斯壯就被幹掉了;這樣的情節我也不是說不能接受,但作者在這部份的敘述太少,跟主情節「憎恨女人的男子」比起來太過虛幻不實,不過或許因為這樣留了很多想像空間,才吸引人吧。

我對於基督教天主教還滿…,嗯,該怎麼說呢,不太能接受的,至於原因嘛,我也不知道,但後來看了一些書(悲慘世界、天使與惡魔…),發現西方文化是離不開宗教的啊,所以我的心態就從以前的避之則吉到現在的想多了解一點。龍紋身的女孩中殘忍連續殺害女人的男子,是一頭病態式模仿聖經批著羊皮的狼,平時人模人樣正常生活,但背後卻虐殺女人;他不是喜歡殺害,暴力與殺人是目的,但重點在追蹤與獵捕,他的資料庫中有一百多個女人的資料,受害者只佔一小部分,「她已婚或未婚?有孩子家庭嗎?在哪工 作?住在哪?開什麼車?教育程度為何?頭髮顏色?膚色?身材?」這種分類工作顯示出一種強烈的興趣,蒐集資料肯定是他性幻想中很重要的一部分,用錄影帶與 照片記錄殺人過程,殺害後還會留下被害人的物品做紀念,用於回想過程,體驗當時的樂趣。看到書中的敘述,我不禁打起了冷顫,真是恐怖的變態啊。

龍紋身的女孩中,作者安排莎蘭德在社會上的一般認知下成為這樣的女孩:「濫用酒精與藥物風險極高、缺凡自覺、內向、受社會壓抑、缺乏同理心、自我依戀、病 態與反社會行為、合作困難、無法同化學習。」只有少數幾個人不這麼想,男主角自然是其中一位,當看了莎蘭德偵搜調查男主角所寫的報告後,男主角不禁想說, 這人恐怕是世界上知道我最多的人了。

到底是智障的精神病患,還是優秀的調查員?

如果只看龍紋身的女孩,不禁覺得,雖然莎蘭德是個值得一寫的人物,但她對於男主角的幫助未免太天兵了吧,因為莎蘭德有通天徹地的駭客本領,所以可以男主角查到很多原本查不到的資料,因為莎蘭德看一頁報告只需十秒左右的時間,所以可以很快地就趕上男主角的查案進度,幫助男主角記住很多資料,因為身為超強駭客而且有管道找人幫忙(要付錢),所以幫助男主角大逆轉跟溫納斯壯間的戰爭,因為莎蘭德,才幫助男主角逃出殘忍虐殺的虎口,等等,總之,如果只看龍紋身的女孩,我會覺得莎蘭德是個不錯的角色人物,但與男主角之間的情節安排不太令我感到合理性,莎蘭德就好像你在霧裡看花,好像看到了卻又看不清處,作者埋了很多伏筆,有些很明顯,有些要到放火的女孩才知道;就這點而言,真的很佩服作者,在第一本給我的印象是那樣,可是在第二本又給了我另一種印象,厲害厲害。建議大家一定要兩本都看,不然會對莎蘭德產生誤解。

在第二本「放火的女孩」中,上述所有的怪異特性都有了解釋,這本可說是專為莎蘭德寫的;用更簡潔的方法證明百年難題費瑪最後定理、為什麼小時候就進去精神病院、天大惡行是什麼、為什麼絕不信任公家機關、莎蘭德的性關係、莎蘭德行為模式的準則為何、等等;書中不斷用不同人的觀點來寫,從布隆維斯特跳到莎蘭德,跳到認為三件命案的兇手是莎蘭德的警官、跳到誰誰誰,這種寫法我很佩服,一方面,作者要很清楚什麼人在什麼時間知道了哪些事而還不知道哪些事,而且每個人個性不同,所知有異,想法不同,會有不同的行動,每個人看其他人會有不同的想法;因為要解謎(命案追查),很多人同時都在解謎,所以作者寫的時候也常常在不同人的大腦中跳來跳去,老實說我覺得這滿難的,因為要小心翼翼,在什麼時間點誰知道什麼誰不知道什麼,誰會採取什麼行動誰會怎麼想,根據劇情演進,有些人又會改變對某些人的觀感於是更改行為模式,我覺得作者經營的不錯,差點就讓我眼花撩亂了,不過這樣讀起來才有趣味在。而作者也透過這樣的方式,讓一些本來認為莎蘭德是個無可救藥的精神病,轉而改變想法,讓本來認為莎蘭德絕不像醫生報告上寫的那樣的朋友們,逐漸了解養成莎蘭德的兒時環境背景與先天個性,讓莎蘭德從第一本中極有懸疑性的角色逐漸在第二本明朗化,真的是不看不行,這樣的一個人物,只有你親自看了才能了解,幹快去買吧。

第三本Luftslottet som sprängdes("The Air Castle that Blew Up"),英文版的書名將會是The Girl Who Kicked the Hornets' Nest,中文直翻是捅黃蜂窩的女孩,英文版聽說會在10月出版,中文版就不知道了,讓我們一邊期待一邊猜想劇情會怎麼發展吧。

以前第一眼看到哈利波特電影中飾演小哈利的童星,就覺得有夠符合心中的想像的;龍紋身的女孩已拍成電影,看著電影海報時,好像對莎蘭德沒什麼感覺,不過話說回來,各國文化不同,當我看著哈利波特英國版跟美國版的封面兩相比較時,或許是長久受到美國文化影響吧,感覺英國版的封面(兒童版)真是難看啊;或許瑞典人對於這樣的選角很滿意,讓我問問我朋友吧。

2009/08/18

日本史 Japan History

看日本漫畫長大的我,曾經被高品質日劇感動的我,經由日式愛情動作片健康教育錄影帶啟蒙的我,常常打信長之野望的我,曾經去日本關西旅遊的我,總而言之,言而總之,想對日本歷史有多一點了解,可是又不想看滿滿都是字的日本史,還好,有這種圖解式的概略歷史書。

某年自己去日本賞櫻,京都二条城內。



書名:日本史圖解
作者:河合 敦
譯者:劉錦秀
出版社:商周


書名:圖解日本史(修訂版)
作者:武光誠
譯者:陳念雍
出版社:易博士出版社


書名:圖解鎌倉.室町時代
作者:河合 敦
譯者:陳念雍
出版社:易博士出版社


書名:圖解江戶時代
作者:河合 敦
譯者:黃秋鳳
出版社:易博士出版社

看到這種歷史書,讓我回想起以前國高中用的歷史課本,國立編譯館出的喔,雖然有有多批評,但我認為大部分的苛責都沒有考慮到那些課本的定位,以那薄薄的頁數不可能將幾千年的中外歷史交代清楚,所以頂多寫出概略的“索引”,每個朝代時期都約略說說,政治經濟文化藝術戰爭興衰朝野人物,對某部分有興趣了解的再找書來看,我覺得照這種標準看來,編譯館的版本寫的算不錯了。

大阪城


而上面這幾本,就好像是我的編譯館版本的日本史,從茹毛飲血的原始文明開始,繩文、彌生、古墳時代,進步到大和政權統一、律令國家、大化革新、遷都平安京,然後是武士時代,鎌倉、室町、江戶幕府,再到近代化的日本,幕末、明治維新與太平洋戰爭,薄薄的一本(前兩本擇一),就可以對日本現代以前的歷史有大致上的掌握,至少知道朝代的先後順序,才不會發生源義經真田幸村的蠢事吧,真是不錯啊,

P.S. 我找不到類似形式的韓國史,有人知道嗎?

我倒是沒看過幾部日本歷史電視劇,不過看電影天與地影武者時,看到熟悉的戰國人物在螢幕上奔馳,真是熱血奔騰啊。另外還有小說,例如山岡莊八的,將歷史書中冷冰冰的文字轉化成有血有肉的人物,將傷亡人數的數字轉換成爾虞我詐的謀略與喊殺震天的戰鬥,不過同時也將索引中幾頁的內容鋪陳為五本十本甚至更多的大作啊。

平安神宮




書名:日本戰國風雲錄(有三冊:天下大勢群雄紛起歸於一統
作者:洪維揚
出版社:遠流

這本是打信長之野望的玩家必讀的著作,裡面以會戰歷史為經,以人物歷史為緯,交錯編織出日本戰國時代的波瀾壯闊 。

作者居然從一代就開始玩,真是厲害,還記得我以前打霸王傳與天翔記時,哇塞,怎麼這麼多城池要攻克啊,從一開始努力種田到後來不斷地出征進攻,雖然說打的很煩失去趣味,不過也反映出戰國時代的情況,在那個年代,因為高山大河等自然疆界的分割,各地大小勢力林立,有只佔據一城從屬於他國的,有擁有一兩國的大名,有寺院忍者海賊地方土豪,合縱連橫錯綜複雜;不僅如此,出場的武將之多,在嵐世記達到1300人以上之譜,在這麼多人裡面我們又能記得幾位呢?

衝鋒陷陣,足輕、火槍、長槍與騎兵。


書中除了介紹對日本戰國時代有重大影響的大名外,例如:毛利元就、長尾景虎(上杉謙信)、武田晴信(信玄)、織田信長、木下藤吉郎(豐臣秀吉)、松平元康(德川家康)、也有介紹在遊戲中能力高超的強力武將,一般說來,對玩家來說,印象深刻的會是在戰場上橫掃千軍的強力武將,譬如說革新中的上杉謙信,車輪一出誰與爭鋒,還有其他比較沒那麼有名的(或者說我孤陋寡聞),龍造寺隆信、鍋島直茂、高橋紹運、立花道雪、島津義久家久、井伊直政、島猛勝等等,在遊戲中雖然用的不亦樂乎,但卻不知其背景,想想真是不該,還好同為遊戲迷的作者寫了這三冊日本戰國時代的參考書,讓我們有進一步的了解。

信長之野望‧革新,織田信長


本來我遊戲打完便罷,不過讀了各武將的背景故事後,又不禁手癢多打了幾次,真是害人不淺啊。

2009/08/13

翻譯:十大挑戰(Ten Challenges)by Steve Yegge

文章: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 BraidDouglas R. Hofstadter

這是有史以來被書寫出來的書籍中,最美麗的著作之一,而且排在我書單最上頭,本書名聲高到難以置信,而且出版那年得了普立茲獎(Pulitzer Prize),雖如此,那不該是你想讀它的原因,這本書是藝術傑作,寫給眾人的書,特別是像你我一樣的程式員。(如果你不是程式員,記得看看書單的第十本。)

關於本書有個趣聞,沒有幾個人曾經看完它,別會錯意了:他們都讀完而且也努力試了,但根據你對於會使頭腦打結之遞迴式矛盾悖論的容忍力有多高,你可能會在三分之一到半路的地方就舉手投降了,我之前就這樣,後來我終於在放假時設法讀到2/3的地方,然後就一直在心理期待著哪天會看完…,所以我想情況還是沒什麼變,我的狀態還是在未完中。

甚至我一些大學教授也不能整本讀完,事實上,我只認識一個人有辦法,他在Amazon工作,不是你心理想的那個人(你大概根本不知道這個人),是個聰明的傢伙,其實在以前研究所編譯器(compilers)上課時,他就是那種當別人使出吃奶力氣忙著寫編譯器的frontend時,他卻已在寫backend的部份了,相當高竿。

我愛這本書,大家都愛,只是沒能力讀完罷了!內容太多太豐富,就好像試著吃掉像小卡車一般大且快融化掉的巧克力乳製蛋糕,我曾經在電視上看過吃冰淇淋的比賽,參賽者一直吃,吃吃吃直到抱著水桶嘔叫,感覺上不能說跟讀這本書的情況不像啊,而且你可以看到過沒多久參賽者眼睛又飄向冰淇淋,想著:「我看還可以再試一次,羅馬不是一天造成的,不是嗎?」

這純粹就是一本天才結晶,而且附著一堆樂趣,不只是因為這是探討智慧(不論是人類的還是人工智慧)的書籍中最好的一本,而且,這本書自己本身呈現出一首自我參照(self-referential)的賦格曲(fugue),居然用書的結構做了一個雙關語向Lewis Carroll致敬。這本書定義了什麼叫做敘述形容,什麼才叫做描寫說明,你就是非得讀一讀不可,即使只到三分之一也好。

我覺得我好像越來越能夠描述出森林的樣子卻又沒進去森林中過,如果你懂我在說什麼的話。

#2: Structure and Interpretation of Computer ProgramsHarold 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!!??”我頭上出現三條線,不管言語上或肢體上我當時可能都被這樣的計畫搞到義憤填膺,見鬼了,他們用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 TypographyDonald 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 PragmaticsMichael 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 LanguagesFriedman, 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 SchemerDaniel P. Friedman, Matthias Felleisen

The Seasoned Schemer是前傳The Little Schemer的繼承之作(當然囉),而且本書也在封面以及每章開頭畫上了開心的大象。

作者們有出另一本書,是一本令人發笑的書,同樣也是以問答的方式呈現,叫做A Little Java, A Few Patterns,我書架上就有一本,雖然你看不到但上面放的都是我真的在乎的書。

那本“Little Java”會讓人想笑,是因為它介紹跟The Little SchemerThe Little MLer完全相同的程式設計觀念與抽象概念,但居然想用Java來寫,其風趣的程度與Ken Thompson的涂林獎演說大致雷同,他演說時提到他辦的Quine競賽:“會有人拿FORTRAN語言來用,原因就跟兩人三腳比賽會流行一樣。”(順帶一題,這是篇好演講。)

如果跳過The Little Schemer最後一章沒看的話,The Seasoned Schemer對你來說就會像一隻的熊,很難殺死,我之前就是這樣,以至於必須回頭仔細研讀一番,這本書立基於之前導出的Y-combinator,一個自我產出遞迴(bootstraps recursion)的重要函式。

此書取了個恰當的書名,真是本難以攻克的一本書,但辛苦留下的汗水是值得的。底下當我談第八本書時,我還會再多說一點為什麼你會動念頭想花那個心力去研讀。


#8: The Scheme Programming LanguageR. 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 ProgramsFelleisen, Findler, Flatt, Krishnamurthi

這是本了不起的書,如果你是個程序員,你絕對不該讀。

沒錯,應該讀。

這本書是給非程序員的,如果你不是,而有想過走進程式設計的世界,這可能是條路,肯定不會輕鬆的那種路,但你將會從最純粹的形式來學程式設計,這本書是寫給還不知道怎麼寫程式的人看的。

程式員不應該看,因為他們通常可以分成兩類:
  1. 已經懂Lisp(或Scheme)的程式員,他們不需要這本書。
  2. 不懂Lisp(或Scheme)的程式員,他們不能理解這本書,因為他們認為學程式設計就是為了餬口飯吃而只需要知道一個語言就夠了。如果你已經是個程式員但不懂Lisp或Scheme,速速遠離此書。
這本書的論點是每個人都應該學會如何寫電腦程式,作者們認為那是每個知識分子都該有的技能之一,或許可算是第四個‘R’──除了原先的讀(Readin')、寫(Ritin')和算(Rithmetic)。

這本書用了一個叫做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日)

2009/08/11

翻譯:十大好書(Ten Great Books)by Steve Yegge

文章: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 HacksExcel HacksAmazon 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來寫大型系統,你最終會要從兩條路選一條走:
  1. 採用AlternateHardAndSoftLayers這個設計模式,大部分的程式碼用高階語言來寫,把跟效能有決定性關聯的部分用C來做最佳化。
  2. 試著把C提升到高階語言的層級,結果咧,不是瘋了去用C++,就是瘋了在沒有任何的語法支援下自己用C來打造高階語言。
多數公司選二,通常是因為他們還沒經歷痛苦學到其實90%的程式碼不需要被最佳化,就算你做了,在執行效能上也不會產生人類可觀察得到的不同。

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工作,希望他們了解我當時只是開開玩笑罷了,別太認真啊。

2009/08/07

But I won't lose no sleep on that

聽歌看電視電影是學英語不錯的方法,話雖如此,但每個人程度不同,要找到適當的教材也不容易,就好像跟比自己英文好的人聊天才會進步,但程度差太多的話又很痛苦;好不容易聽懂(看懂?)了Friends,但碰到The Big Bang Theory(宅男行不行or生活大爆炸or天才也性感)就舉雙手投降,速度快又有很多專有名詞,唉。

四個宅男跟一個金髮辣妹的組合。


有次在學一首歌,歌名:You're Beautiful,歌手:James Blunt,不懂其中一句,所以請教Sally,其實大概知道意思啦,不過趁機跟英國人聊聊也好,呵呵。



This is Sally, from England.


歌詞:
My life is brilliant.
My love is pure.
I saw an angel.
Of that I'm sure.
She smiled at me on the subway.
She was with another man.
But I won't lose no sleep on that,
'Cause I've got a plan.

You're beautiful. You're beautiful.
You're beautiful, it's true.
I saw your face in a crowded place,
And I don't know what to do,
'Cause I'll never be with you.

Yeah, she caught my eye,
As we walked on by.
She could see from my face that I was,
Fucking high,(Real version)
Flying high,(clean version)
And I don't think that I'll see her again,
But we shared a moment that will last till the end.

You're beautiful. You're beautiful.
You're beautiful, it's true.
I saw your face in a crowded place,
And I don't know what to do,
'Cause I'll never be with you.

You're beautiful. You're beautiful.
You're beautiful, it's true.
There must be an angel with a smile on her face,
When she thought up that I should be with you.
But it's time to face the truth,
I will never be with you.

有點不懂But I won't lose no sleep on that,lose sleep on something,大概就是因為某事而失眠煩惱的意思,可是為什麼會有兩個否定(not/no)呢?Sally說:this is just a song, so don't take it too serious. Two negatives is meaningless.

雖然如此,不過還是會聽到類似nothing impossible、There's nothing I can't do之類的句子,或許文法上有所規定,但在歌曲以及一般口語時,就沒有太多講究了吧,聽得懂就好。

鐵達尼老梗,不過做出來還是很好笑(要看時機啦)。



居然有人kuso改歌詞,真是搞笑啊。

2009/08/06

靈劍(by 鄭丰)讀後感

注意:免不了會提及故事情結,小心踩雷。

書名:靈劍(共三卷)
作者:鄭丰(陳宇慧)
出版社:奇幻基地


之前看了鄭丰的天觀雙俠,覺得很不錯,這次看到第二部作品出來了,馬上就整套買回家,雖然有點衝動,但看完後也沒後悔。

故事內容是天觀雙俠的前傳,主角是凌霄跟燕龍,反派則是火教教主段獨聖,在天觀雙俠中所用到的背景,例如百花門、火教、龍幫以及其他門派幫會武林世家的關係,比翼雙飛為何不是凌霄的兒子、火教的覆滅、虎俠、九老、凌霄陳近雲許飛的結識過程、等等等等,都在靈劍中一一呈現、

先看了後面的情節(天觀雙俠),然後再看前傳(靈劍),會給我一種悶的感覺,因為已經知道概略的結局,以至於在閱讀的過程中沒有了懸疑性的那種微妙心理狀態,接下來會怎樣呢、為什麼會這樣呢;所幸,靈劍有凌霄燕龍段獨聖,這跟趙觀凌昊天是相當不同的人物,作者可以花心思塑造,舖設情節,這樣就不會看的很煩。(看某本武俠小說時,雖然裡面人物一堆,而且每個角色的篇幅都很夠,但總覺得看來看去都很像。)不知道何時曾聽過這麼一種說法:「不懂的看情節故事,內行的看人物角色。」我想這應該是小說要成功的重要元素之一,能夠讓讀者深深記得書中的人物,如同躍然紙上一般,其性格與特質,給人的態度與展現出來的風範,即使在闔卷後,仍能縈繞心中;我覺得霄龍就有給我這樣的感受,段獨聖似乎就只算是一個普通的大魔王而已。

不過武俠小說的主角怎麼都是絕頂的資質、萬中無一的絕世高手啊!沒錯,你也是,要不要買本秘笈啊。


要創建一個世界是非常非常困難的,因為我們已經有一個熟捻的世界,也知道運作的法則(物理定律、人類社會、大自然),為了創造新題材,需要改變,只加入一點小改變也就只會有一丁點趣味,加入大改變才能大大地吸引人,例如各種超能異能變種人的題材,但是大改變後的世界還能夠是平衡的嗎?金剛狼在萬磁王前是個廢物,有特異功能搓牌不就贏定了,就這點而言,我滿喜歡JoJo冒險野郎所描述的架構,雖然有各種奇奇怪怪的替身,但沒有絕對不敗的能力;有點離題了,讓我拉回來,靈劍這部武俠小說的第一卷,加入了靈能這個要素,可以知道別人在想什麼,而且可以預測未來,哇賽,太強啦,因為如此,才有了火教神聖教主段獨聖,也因此,讓凌霄成了一個很怪異的武俠人物,他可以預知接下來的混戰雖小勝但某姑娘會被劫走,所以預先去保護,不過在某些時候,作者又不安排他用,用跟不用的情節會差很大,又沒說為什麼不用,這就會讓我很鬱悶,感覺這能力不是書中角色擁有的,而是作者想要就有沒注意就漏寫的,哎呀,這樣就我看來就是漏洞,就不完整。

這漫畫裡面角色人物的替身的命名很有趣,很有想像空間。第五部主角替身名為黃金體驗,我還是不太能體會其意涵。


第二卷引出了燕龍跟龍幫,雪族雪艷跟中原的瓜葛,燕龍跟凌霄如何終於走在一起,故事中不免要加入一些曲折、困難、心有隔閡,不然兩人一見面就白馬王子跟白雪公主過著幸福快樂的日子,那還有什麼搞頭啊,只不過有時候安排的不合理就又會讓我很悶,明明兩人已經到了心心相映的程度,卻又搞個小誤會,然後又大和解,哇哩咧,根本在耍我嘛。譬如到了第三卷,兩人約好要一起去打哪裡,男的突然傳訊息來說不能去,女的就以為他只顧著寶貝妹妹,女的去了以後遇到危險心中有所埋怨,男的又來解圍,可是男的卻詛咒發作,於是女的才知道男的是因為知道詛咒可能會發作所以才不能跟她一起去,於是兩人又噁心兮兮談情說愛,哇哩咧,那男的一開始早講不就好了,昏倒。

要讓人入迷莫過於安排謎題,譬如哈利波特,安排大大小小長的短的謎團;書中貫穿三卷的是二十四個字的嘔血籤辭,雖然讀者一開始就看到,但也不能盡解;失去記憶的明兒是否就是凌霄,另外火教為什麼能成長的那麼大,靠的是什麼,龍幫是從哪冒出來的,為什麼要挑戰六大門派搶龍湲劍,為什麼為什麼,就等你去閱讀去尋找了。

不論如何,我覺得靈劍是部成功的前傳,雖然讀起來沒有像天觀雙俠那麼有趣,作者也說靈劍是比較陰暗悲慘的,但我認為它有成功地把該有的背景、情節、故事都交代出來,算是天觀雙俠的背景設定書吧。於是,開始期待鄭丰的下一部作品。

2009/08/04

Boots, Boobs & Booze

曾經在西澳的一家豬肉屠宰場工作一個月,天氣冷工作辛苦(居然練出小小的肌肉,不過現在也沒了),大體而言是不錯的經驗,除了那邊的菲律賓人不太友善外。有天跟照片右邊的英國人Joe聊天,聊到負責管理我們的工廠代表的口音(澳洲中年男子),我說我只能聽懂20%(等於有聽沒懂),他說他也聽的也很吃力,雖然有點小安慰,不過我還是滿沮喪的。


後來不知怎麼聊的,我說我之前有學到一個新單字booze,然後他好像要考我吧,就講了三個單字,我只聽到『噗茲 噗茲 噗茲』的,真是難分辨啊,請他多念幾次,總算可以分別出來,不過如果是在句子中出現,還是只能用上下文區別吧。


boots 靴子


在澳洲有看到這種UGG靴子,不過事實上遠在十幾年前鳥山明早就創造出這種流行時尚了。



boobs 胸部
這我就不多說了,可以看看這裡的解釋



booze 酒


沒想到居然有這種booze bra,可存酒的胸罩,真是有創意啊,orz。



看樣子不只我,連外國人也分不清楚這三個字啊。I hate the RHYME of WORDS.

嗯,大家分清楚了嗎?:)


2009/07/15

讀後筆記:散戶流浪記

書名:散戶流浪記:一個門外漢的理財學習之旅
原書名:A Fool and His Money:The Odyssey of an Average Investor
作者:John Rothchild
譯者:黃佳瑜
出版社:早安財經


這本書是寫給有這種想法的人:『如果自己有時間好好研究一下股市,應該可以發點小財』。在書的最後面有份傻瓜辭典,是我看過最精闢的投資理財文字敘述,例如:

  • 散戶:天生輸家。
  • 多頭市場:市場走勢上揚;鄰居手上的股票翻騰上漲。
  • 回檔修正:背離上漲走勢的短暫下挫;投資人遭遇空頭市場時一廂情願的想法。
  • 投資組合經理人:替共同基金、退休基金操盤的投資專家;表現落後大盤,卻仍領取高薪的人。
  • 重整:企業內部的調整,用來提高股東權益,隱瞞重大錯誤。
等等等等,在此就不詳列了。以我的財經知識也不能多做評論,以下是我寫給自己看的一些筆記。


前提:認為金錢不代表一切的人,永遠無法擁有足夠的金錢。

散戶:高買低賣的人

散戶:不知道財經世界運作法則卻還想靠股市、債券、基金、選擇權、期貨賺錢的人

怎麼選銀行存錢:愛因斯坦說:『 複利的威力勝過原子彈』,既然如此,不了解原子彈的我也不會懂得複利,既然不了解複利與單利,那就無法了解下列各種產品服務的差別了:一年期定存、機動利率活儲帳戶、支票加儲蓄帳戶、有最低存款金額限制、免手續費等等。

財務健康檢查:財務規劃公司將幫你省下的錢放進他們的口袋,所以,散戶就免了吧。

投資指南:航海時要帶一或三個指南針,帶兩個不行。這句話告訴我們,看投資理財的書要看奇數本,因為每多看一本,出現的建議往往跟前一本大相逕庭。例如:千萬別太早脫手vs殺出永不嫌遲、賺錢的股票不要脫手vs儘快落袋為安、等等。只有一條原則是被一致認同的,5%的人就靠95%的傻瓜發財。

反向操作:反向操作遇到的第一個問題是要反誰,互相矛盾的說法充斥著各個角落;第二個問題是,如果大眾也開始採取反向操作主義,那你要反的是?

證券營業員:優先推薦的往往是讓他們賺取最高佣金的商品;不必太高等的營業員就能夠在簡短的談話過程中改變他們的基本投資哲學,依憑的就是對你的觀察。所以當個營業員的必修課程是戲劇課,而不是會計、企管、財務分析等等。

理財顧問、理財規劃師:a.k.a. 證券營業員,不管名稱為何,其本質仍為業務。

技術面派vs基本面派:其差異可能比藍綠還大,但酒會上大家可都是交談甚歡。

聰明的投資人還沒跑:這句話居然能夠把證據確鑿的失敗跡象(例如下滑的股價),扭轉為成功的訊號。

股價為什麼會上漲或下跌:怎麼說都行;只要有心,人人都可以是老師。

多頭市場(bull market)、順市(swimming market):大部分人都賺錢的時候。

空頭市場(bear market)、病市(sick market):大部分人都賠錢的時候。

散戶:總是說自己績效"大概打平"的人,其實是花了錢又花去時間,最後發現與其自己投資不如給人出意見。

紐約證交所、美國證交所、店頭市場、芝加哥期貨交易所與商品交易所:賭注變成了投資的地方。

期貨:是讓你在承諾日之後,以今日議定價格,買進某件東西的協議。在期貨合約中,買賣雙方皆必須負起履行交易的義務,與商品命運與共。

選擇權:則是合約的合約。賦予買方權力,購買或許有價值的商品,卻沒有履行交易的義務。

買入買權、賣出賣權、賣出買權、買入賣權:前兩個代表你期望價格上漲,後兩個代表你期望價格下跌。

聯儲會:銀行的銀行,靠著在準備金餘額上多打幾個零或抹去幾個零,來控制通貨膨脹或緊縮銀根,無形中民眾的錢就被掠奪了。

內線交易:從外線聽到的內線消息而去做的交易不算是內線交易。

賣方分析師:一:公司的副總透過分析師間接地回頭向企業解釋企業原本即已知道的營運狀況。二:向大戶提出意見,而大戶才可能從他們口中聽到賣出兩字。

買方分析師:一:給賣方分析師打分數。二:聆聽所有的消息面以及八卦,然後向投資組合經理提出選股建議。

投資組合經理人:位居金字塔頂端,只要跟其他人一起協議好,績效就會差不多,飯碗就保住了,等於是坐領高薪卻又沒風險。

打敗大盤:全世界只有少數幾個人做得到,所以不要浪費時間了,乾脆買指數型基金吧。

買空賣空:賣出不屬於自己的東西然後再買回還人。

:最初定義是指耍手段哄抬價格的操縱者。

:最初定義是指暗中搞鬼壓低價格的放空人。

套利:投資某一個方向,同時又押注另一個方向,好確保無論結果如何,你都有利潤;也就是要尋找每一次轉手的保證報酬。

差價套利、跨式部位、多頭價差、空頭價差:總之,不管你懂不懂,當在操作時,千萬不要把家裡的生活費拿來當保證金。

期貨市場:偽裝成保險的龐大賭局;期貨交易是合法化的賭博。成長趨緩時就表示笨蛋的荷包暫時被掏空了。

買進價內買權、賣出價外買權;(作者不想費事解釋。)

投資神祕的地方:賣掉賠錢股票之後看著它繼續下跌,比看見一檔讓我賺到錢、但獲利了結後卻繼續走高的股票,更讓人開心。

不論是不是散戶:跌兩百點叫苦連天,跌三百五十天卻振作起來,因為已經神智不清。

散戶:患有投資人失憶症,為了重返股市,不惜抹去先前血本無歸的教訓。


這完這本書後相當傷心,散戶真是可憐啊。

2009/07/11

翻譯:如何"別"在網路上打廣告(How Not to Advertise on the Internet) by Jeff Atwood

文章:How Not to Advertise on the Internet(如何"別"在網路上打廣告)
日期:2009.07.09
作者:Jeff Atwood
作者的部落格:Coding Horror


如何"別"在網路上打廣告(How Not to Advertise on the Internet)

現在正流行著在瀏覽器上玩遊戲(網頁遊戲),想想也很合理,這可是有著世界上最大的使用族群,技術上完全免費可得,不用付任何的授權費用,為什麼不在其上開發遊戲呢?有個這樣的遊戲叫做Evony,之前叫做Civony ─ 是文明帝國的瀏覽器版,加上線上購入的機制。


現在也會有很多機會讓你'掏錢'出來的,再怎麼說,Civony仍然是商業性質的,老實說,與其讓所有人都付月費或被迫接受遊戲中的廣告,不如讓一些重度玩家有選擇性地掏錢,反而我覺得是比較好的作法;除了之前的每行$0.30聊天費,你也可以經由付費來加快資源蒐集速度,提高統計數字,還有買遊戲中的寶物。一定還有其他我沒發現的付費方式,不過每當你看見綠色的加號(+),那就是要誘使你掏錢了。

這遊戲表面上是免費的,但其實是由一小群的玩家付費買東西來支撐的(有時候稱為"freemium",玩免錢,但可以花錢買特殊寶物或能力),所以,要有相當大量的玩家才可能持久經營這遊戲,而且遊戲創作者定期地購買網路廣告來做宣傳。至今為止,關於Evony最有趣的點不在遊戲本身,而是遊戲的廣告,下面是一個早期的廣告。



很適當的廣告,一看就想到這是設定在中世紀時期的遊戲,而且強調是免費的。

顯然地,那廣告沒有達到Evony總部的預期目標,因為廣告逐漸逐漸地 ...,嘿嘿,自己看看吧。下面以在網路上出現的時間從以前到現在順序排列。



(這小姐看起來眼熟嗎,原因在此









為求公正,這些是的有出現在網路上的廣告,可不是造假的,有圖有真相,下面是把在網站The Elder Scrolls Nexus出現的畫面拍起來。



我已經談過打廣告也要有責任感,而這個案例恰恰跟我講的背道而馳,剛好是另一種形式,悲哀啊,證明了那傑出的諷刺作品 蠢蛋進化論(Idiocracy) 是對的。



蠢蛋進化論(Idiocracy)中反面烏托邦式的未來預測了廣告將會無法避免地低俗到一個最小公倍數,星巴克異國情調咖啡-限男性,H.R. Block的"成人"退稅(紳士們退款的家),還有Pollo Loco在廣告雞翅桶時附上"整套服務"。

Evony,感謝你告訴我們把網路廣告弄的這麼低俗代表了什麼意義,可以再低一點,在岩石下繼續挖地下室,繼續挖挖挖,直到抵達白熱融化的地球核心,我過去總是想著那會是怎樣的一個光景,我猜現在我知道了.

2009/07/07

讀後小失望:這些創意不是亂講

這些創意不是亂講 - 王偉忠團隊的13堂獨門創意課
作者:王偉忠.陳志鴻/合述,王蓉/整理
出版社:天下文化
ISBN:9789862162620


全民亂講2100-全民大悶鍋-全民最大黨

小時候看連環泡,除了看裡面演的短劇,還有年紀小看不懂的老實樹,最喜歡的一個單元是:打開中國電視史,記得其中一集是"小虎旋風篇",哇,講的就是小虎隊ㄟ,當時感覺非常新鮮,後來長大,才知道製作人跟中國電視史的旁白是王偉忠先生。

這本書就是講全民亂講2100-全民大悶鍋-全民最大黨裡面的創意發想,可惜的是,可能我抱的期望太高,書中講的我大概都已經知道了解(當然,知道歸知道,做是另外一回事),我覺得創意歸一回事,節目成功的關鍵在於那些演員的模仿能力。

有次聽賴聲川演講,有記得一個點,大家都強調創意,那執行能力呢?今天假設有個新的模仿對象出來,有哪些關鍵點要表達出來才會覺得像,要怎麼改、惡搞才會好笑,要怎麼編新內容想新台詞才不會曇花一現,創意很重要,但不能輕忽其他部分啊。

老實說我覺得這本書有點來撈錢的,不出白不出,節目很好,製作人編劇也很棒,但這本書就遜掉了。

2009/06/28

Awesome and Awful

awesomeawful滿常聽到的,兩個字也長得很像,可是卻代表恰恰相反的意思,awesome表示棒極了,awful表示糟糕的,為什麼呢?

感謝HotForWords提供解答。


原來呀,awesome跟awful都是由awe而來,而awe是從古英語ege而來,其意為:immediate and active fear; terror, dread,也就是有"害怕恐懼"的意思,後來逐漸演變為:fear mixed with reverence and respect,摻雜進"崇敬"的意思,所以現在我查字典,awe的意思是"畏怯敬畏"的意思,由本來代表負面的意義逐漸變成表示有正向的意思。

awesome是由awe跟some組合而成,而字根some之意為characterized by。

aweful是由awe跟ful組合而成,而字根ful之意為full of或是characterized by。

所以原本兩個字代表同樣的意思,但十九世紀早期,人們開始把awful拿來當做adverbial intensifier,用來加強語氣的副詞,而且通常用來加強壞的方面的形容。例如:it's awful lonely here(不只寂寞,還強調很~~寂寞)或是it's an awful hot day(真是熱到蛋蛋都熟了啊),於是awful就變成負面的意思了。

哇,原來如此。下面舉幾個例子。

譬如你去看了變形金剛2,別人問你怎麼樣,你想要回答正面的意思,就可以用:awesome太強了。


或是你朋友說她有去sky dive,你也可以說:awesome太厲害了。


或者去Cradle Mountain但雲層很厚,你可以說,the view was awesome but the weather was awful,天氣糟透了。


或是上班遇到New Girl,或是公司有機車人,過了很ㄍㄢˋ的一天,你就可以說:I had an awful day!


記起來了吧。

2009/06/25

讀後介紹:一個人去旅行 ─ 高木直子

書名:一個人去旅行
作者、繪者:高木直子
譯者:陳怡君
出版社:大田
出版日期:2007年10月
ISBN:9789861790725


官方網站:中文日文


這本書我看了好幾次,每次都是在書店站著看的...orz,現在終於買回家了。當初為什麼會翻來看呢?因為我之前自己有去日本自助旅行,所以看著這種圖文書,又不像在看一般的旅遊書,又不像在看字很多的旅遊文學,看到我也去過的地方就覺得有共鳴,看到沒去過的地方就幻想著我下次也要去也想去,一整個心情都愉悅起來了。



內容有:
日光鬼怒川篇、鎌倉篇、長野善光寺篇、花卷溫泉篇、博多篇、京都篇、三重篇、沖繩篇。

鬼怒川搭船、宇都宮煎餃、鶴岡八幡宮、鎌倉最古老的澡堂 瀧乃湯、神社卦單、泡溫泉後把臉埋進雪裡、從東京搭夜行巴士到博多(14.5小時,1150公里)、天神的路邊攤、沖繩考潛水執照、京都舞伎變身、三重的赤福、還有各地不同風情的旅館以及不同風味的拉麵,哇哩咧,有沒有這麼有趣啊,好想去喔。

作者是日本人,日本治安又這麼好,技術上來說就算一個人在日本旅行應該也沒什麼困難才是,不過看書就會知道,直子小姐有些地方很必素ㄟ,想去某間店品嚐美食,會在外頭觀望一陣子,然後要提起勇氣才敢進去,如果是那種外面看不到裡面情況的店,就真的不敢進去,真是有點好笑~呵。

直子小姐跟賭神一樣,採訪時是不接受拍照的,我只找到這兩張照片。所以我也不能確定這兩張是不是真的是她本尊。



看起來直子小姐的書應該賣的滿好的 ,不然出版社不會一直翻譯出版吧?包括:150cm Life、一個人住第5年、一個人上東京、150cm Life2、一個人的第一次、一個人泡澡、150cm Life 3、一個人去旅行、一個人漂泊的日子、我的30分媽媽,哇!好多啊。

不過我想看的是這兩本:ひとりたび2年生、愛しのローカルごはん旅,算是一個人去旅行的續作,我寫了email去問出版社,說會出,應該是還在翻譯中吧。(不過出版社犯了我的大忌,居然一直回送廣告信給我,真是ooxx。)