●電腦技術的專有名詞和術語 -- 侯捷

[[e-mail]]

作者: jjhou (jjhou)
標題: ●電腦技術的專有名詞和術語 -- 侯捷
時間: Wed May  6 15:57:48 1998


●電腦技術的專有名詞和術語 -- 侯捷

前些日子收到讀友一封 email，談到他在 multi-threading 的一些經驗，
以及幾個中文譯名的看法。我也發揮了一些想法。請大家共享。

> 侯先生您好:
>
>    日前拜讀您近來的一本譯作（97年8月出版, 勉強算是"近來"吧! :)）
> 也就是「Win32 多緒程式設計」一書，收獲甚多。原本只靠著幾個 API
> 和 system call，加上修作業系統這門課時對於 multi-thread 系統及
> 數個古典 IPC 問題的粗淺認識，在 Solaris 和 Win32 平台上寫一些
> 多緒程式，算得上是一招半式闖江湖。多日前在書店架上看到這本
> 書時，心中還在思考：多緒程式還不就這樣，需要花一本書來談嗎？不過
> 左右無事，加上又是您所譯，向來品質保證，就買了一本回家。買
> 回家後發生了一些事，遲遲沒有時間詳讀。直到今天，坐車南下去
> 探視女友（好感人的鵲橋相會.:P），才利用漫長的交通往返時間一鼓作
> 氣地把它讀完（當然，並沒有仔細 trace 書中的 source code）。這才
> 發現事實和想像的差距甚大.

>     先前使用的一些 Win32 同步機制，像是 CRITICAL_SECTION 或是
> Mutex，都感覺有點不對勁，因為和課本中所讀到的 mutex 有些性質
> 上的差異。其實我犯的錯誤是，沒有真正深入去了解這些同步機制
> 在 Win32 平台上的實作細節。教課書中所提到的 mutex 或是
> semaphore 等同步機制，多只論及抽象意涵；但在實作上，
> 各系統各有其因地制宜的細節存在。如果沒有真正了解這些實作上的差
> 異，一方面無法切入系統核心，只能瞎子摸象，一方容易衍生出因為錯
> 誤認知而產生的程式臭蟲。

我很同意你的說法。理論的東西和實際的產品多少有差距，有些甚至連名詞
都不一致呢！而且各系統之間也可能存在些許差異。這些因素放到實作面上，
都攸關專案的成敗。

> 讀完「Win32 多緒程式設計」之後，只能說是獲益良多，也感謝您
> 能選擇翻譯這本好書。雖然您家裡可能早就塞滿了"惠我良多"的扁額，
> 我還是要跟您說聲謝謝!

很開心聽到你這麼說。這就是我鎮日埋首書堆之中，最大的安慰了。

每一位用心的作者譯者，都值得（並且迫切需要）這樣的鼓舞。
請別吝於給他們掌聲。

>     寫這封信的動機除了和您分享讀書心得外，還有一點就是關於
> 譯本第 182 頁，講到 127.0.0.1 是近端（local）機器的一個別名。我
> 對 local 譯成近端有點小小的看法（可不是班門弄斧唷）。IP Address
> 在規範時，把網路編號為 127 的位址拿來做 loop back 用，這個位址
> 不會送出主機之外，所以譯為「本地」似乎會較符合其意。
>
> -- Qing

言之不無道理。譯為近端（local）是為與遠端（remote）有個對應。

我心目中最理想的譯法，就是對於這類字眼根本不譯。我所挑選的主題，
其潛在讀者一定都有能力接受這些原文名詞，所以，從我目前手上的
書開始（Inside The C++ Object Model 和 Essential COM），我開始
大膽地嘗試我的理想。

過去有太多朋友告訴我，他們閱讀中文電腦書籍，不論是著作或
譯作，如果不計較那些誤謬不知所云的可憐作品，最大的閱讀困
難還是在於一大堆沒有標準譯名的技術名詞或習慣用語。其實，
就算國立編譯館有統一譯名（或曾有過，誰知道？），流通於工
程師之間的還是原文名詞。

對於工程師，我希望我所寫的書和我所譯的書能夠讓他們讀來
通體順暢；對於學生，我還希望多發揮一點引導的力量，引導
他們多使用、多認識原文術語和專有名詞，不要說出像
「無模式對話盒」這種奇怪的話。

當然，有些中文譯名夠普遍，也夠有意義，我並不排除使用。
至於其間的挑選與決定，當然就帶著點個人色彩了。

對專有名詞或術語的這種理念，打從我寫第一篇文章開始，就存在了。
為什麼漸次地才日益加重其份量？雲南有句俗語說：成了龍形再現爪！
在我終於贏得許多人的信賴之後，我現在可以照我的理想去做了。
當然，我希望大家能夠接受，也希望聽聽大家的意見。

--- end

--
※ Origin: 楓橋驛站<bbs.cs.nthu.edu.tw> ◆ Mail: [e-mail]
※ X-Info: Mave -> [e-mail]
※ X-Sign: 0ROAATGPHI8KfMDAOG.. (99/07/09  6:52:32 )