惡紫之奪朱

侯捷

2003/08/31


■傳送日期: 2003年8月14日 PM 03:26
侯捷先生
看了這個您有什麼感想 :)

 

主  題: 狂罵侯捷
作  者: bigwhiteshark (大白鯊:專業程序員)
所屬論壇: 擴充話題 技術書評
發表時間: 2003-08-13 00:24:17

狂罵侯捷

侯捷何許人也? 他乃是台灣人,中華民國人.
侯捷的近段時間在中國名气很大,有些傻瓜還把他捧為神明.
其實他自己說是個書商而已啦.
他之所以成名在于所翻譯的書都是好書,加上自己的職業道德,普通計算机軟件技術,和台灣方便的与國外出版社勾通的商業環境.
中國很多作者和譯者在今天的社會環境中,職業道德早忘記了,計算机軟件技術水平不合格, 沒有良好的与國外出版社勾通的商業環境,在不停地追逐金錢下產生了很多垃圾書.
當侯捷進入了中國市場后就帶來了很多精品的技術書籍.
<<深入淺出MFC2>>
<<C++設計新思維>>
<<More Effective C++>>
<<深度探索C++對象模型>>
<<C++標准程序庫>>
等等….
我罵他并不是沒有采用中文術語….而是在于他的風格,這种風格使人要多看几遍才能懂得一二,每一遍的閱讀速度很慢.
他的風格是采用大量的英文,小挎號( ),中挎號[ ] 翻譯原作是逐句翻譯,上下文不通…..
他的風格我沒有權利去評价,但是他翻譯成簡体中文并在中國范圍內發行.就不得不狂罵牛句.

More Effective C++ 侯捷翻譯

1.1 Item M18:分期攤還期望的計算

在條款M17中,我极力稱贊懶惰的优點,盡可能地拖延時間,并且我解釋說懶惰如何提高程序的運行效率。在這個條款里我將采用一种不同的態度。這里將不存在懶惰。我鼓勵你讓程序做的事情比被要求的還要多,通過這种方式來提高軟件的性能。這個條款的核心就是over-eager evaluation(過度熱情計算法):在要求你做某些事情以前就完成它們。例如下面這個模板類,用來表示放有大量數字型數据的一個集合:...

假設min,maxavg函數分別返回現在這個集合的最小值,最大值和平均值,有三种方法實現這三种函數。使用eager evaluation(熱情計算法),當min,maxavg函數被調用時,我們檢測集合內所有的數值,然后返回一個合适的值。使用lazy evaluation(懶惰計算法),只有确實需要函數的返回值時我們才要求函數返回能用來确定准确數值的數据結构。使用 over-eager evaluation(過度熱情計算法),我們隨時跟蹤目前集合的最小值,最大值和平均值,這樣當min,maxavg被調用時,我們可以不用計算就立刻返回正确的數值。如果頻繁調用min,maxavg,我們把跟蹤集合最小值、最大值和平均值的開銷分攤到所有這些函數的調用上,每次函數調用所分攤的開銷比eager evaluationlazy evaluation要小。

隱藏在over-eager evaluation后面的思想是如果你認為一個計算需要頻繁進行,你就可以設計一個數据結构高效地處理這些計算需求,這樣可以降低每次計算需求時的開銷。

采用over-eager最簡單的方法就是caching(緩存)那些已經被計算出來而以后還有可能需要的值。例如你編寫了一個程序,用來提供有關雇員的信息,這些信息中的經常被需要的部分是雇員的辦公隔間號碼。而假設雇員信息存儲在數据庫里,但是對于大多數應用程序來說,雇員隔間號都是不相關的,所以數据庫不對查抄它們進行优化。為了避免你的程序給數据庫造成沉重的負擔,可以編寫一個函數findCubicleNumber,用來緩存查找到的數据。以后需要已經被獲取的隔間號時,可以在cache里找到,而不用向數据庫查詢。

以下是實現findCubicleNumber的一种方法:它使用了標准模板庫(STL)里的map對象。

<<深度探索C++對象模型>>;更為嚴重,給人以濫竽充數感覺….

*** 侯捷註:接下來是一些激烈的政治言論,此處略 ***

...反過來你們也不要強奸我們,不要以中國的名義翻譯海外优秀技術書籍,壟斷翻譯權.使得我國作家沒有權利翻譯同樣的書籍,我們這些讀者沒有選擇的權利,從而我們不得不忍受你們該死的風格.

 

■侯捷回覆

針對侯捷而發的激烈言論,三年來我看過不少,不復有太大漣漪。此文雖口出惡言,但畢竟「舉證歷歷」,還是應該端正心情仔細檢討。

文中所引的是《More Effective C++》簡體版,這是很被大家稱讚的一個譯本,怎麼會得此惡評?難道讀者的口味差異這麼大?於是我正襟危坐,仔細閱讀一遍。

嗯,確實不通順,但…為什麼身為譯者的我對這些文字和其文風如此陌生呢?是農曆七月靈異事件嗎?於是我拿出我的電子檔,攤開手邊的簡體版紙本。下面是侯捷簡體版譯本的對應內容:

條款18:分期攤還預期的計算成本

在條款17中,我讚揚了拖延戰術(laziness)— 也就是儘可能把事情延後執行 — 的價值。我也解釋了拖延戰術如何改善程序性能。本條款中我將站在一個不同的位置,在這裡拖延戰術無著力點。現在我鼓勵你改善軟件性能的方法是,令它超前進度地做「要求以外」的更多工作。此條款背後的哲學可稱為超急評估(over-eager evaluation):在被要求之前就先把事情做下去。

舉個例子,考慮一個 class template,用來表現數值數據的大型收集中心:...
假設 min, max 和 avg 三個函數分別返回該數據群當時的最小值、最大值和平均值。這些函數的實現法有三種。第一種是使用 eager evaluation,於是我們在 min, max 或 avg 被調用時才檢查所有數據,然後返回檢查結果。第二種是使用 lazy evaluation,於是我們令這些函數返回某些數據結構,用來在「這些函數的返回值真正需要被派上用場」時,決定其適當數值。第三種是使用 over-eager evaluation,也就是隨時記錄程序執行過程中數據集的最小值、最大值和平均值,一旦 min, max 或 avg 被調用,我們便能立刻返回正確的值,無需再計算。如果 min, max 和 avg 常被調用,我們便能夠分期(逐次)攤還「隨時記錄數據群之最小、最大、平均值」的成本,而每次調用所需付出的(攤還後的)成本,將比 eager evaluation 或 lazy evaluation 低。

Over-eager evaluation 背後的觀念是,如果你預期程序常常會用到某個計算,你可以降低每次計算的平均成本,辦法就是設計一份數據結構以便能夠極有效率地處理需求。

其中最簡單的一個作法就是將「已經計算好而有可能再被需要」的數值保留下來(所謂caching)。例如,假設你寫一個程序用來提供職員信息,而你預期職員的房間號碼在此程序中常常會被使用。更深一層假設職員相關信息存儲在一個數據庫中。由於大部分應用程序並不需要職員的房間號碼,所以這個數據庫並沒有特別針對此字段做優化。為避免這個有著特殊應用的程序重複不斷地尋找職員房間號碼而造成數據庫的不當壓力,你可以寫一個 findCubicleNumber 函數,其中會將它所找到的房間號碼記錄下來。後繼再有房間號碼的查詢需求時,如果該號碼已取出,就可藉由高速緩存(cache)而完成任務,不必再查詢數據庫。

下面是 findCubicleNumber 的一種實現法,其中使用 Standard Template Library("STL" - 見條款35)提供的 map object 做為一個局部緩存:

署名「專業程序員」的網友,不知哪兒弄來那麼一份文字,大喇喇說是侯捷譯本,然後大加撻伐。如果說到點子上,罵到正主兒,即使言詞粗鄙也有其價值,可這卻…。

我缺乏興致去設想這是怎麼回事。真的,我厭倦了這些奇奇怪怪的事情 !!

惡紫之奪朱,惡鄭聲之亂雅樂,惡利口之覆邦家。

-- the end