# 十七、源于計算機學科的三個錯誤思想 我并不是要潑大家冷水，不過坦白講信息科學里有三個重要的想法是錯的，而且大家也開始 注意到了 ..為了你自己好請忽略它們。 我相信還有其他的，不過這是最讓我感冒的三個： 1. 搜尋的困難之處在于找到足夠的結果， 2. 去銀齒(anti-aliased)的文字比較好看，還有 3. 網絡軟件應該讓網絡資源的行為和本地資源一模一樣。 嗯，我只能說， 1. 錯， 2. 錯， 3. 全部都錯！ 讓我們來個簡短的巡禮。 ## 搜尋 大部份搜尋的學術研究都一定會被類似的問題所困擾：比如「如果搜尋”ca「”，可是想要的 文件內用的卻是”automobile”，這時要怎么處理？」 事實上極大量的學術研究在探討多形態(stemming)之類的概念，在這個概念下你所搜尋的字 會被去結合（de-conjugated)，所以用”searching”來搜尋時，也會找到內含”searched”或 “sought”的文件。 所以當Altavista這種大型Internet搜索引擎剛出現時，都在宣傳他們可以找到很多很多的 結果。用Altavista搜尋Joel on Software會得到1,033,555個網頁。這種結果當然是無用的， 目前己知Internet大約有十億個網頁(譯注：當時是公元2000年），Altavista把十億個網頁 縮減成一百萬個，對我來說是完全沒有意義的。 搜尋真正的問題在于如何將結果排序。不過要為計算機科學家辯護一下，除非有人開始拿 I nternet這么巨大的數據來做索引，否則根本不會有人注意到這一點。 不過還是有人注意到了。Google的Larry Page和Sergey Brin了解到，以正確的順序呈現網 頁ranking，比把所有可能的網頁都抓來要重要多了。他們的PageRank算法是個很好的方法， 可以對很龐大的結果進行排序，讓你所要的結果很可能列在前十項。事實上用Google搜尋 Joel on Software就會看到它出現在第一項。用Altavista搜連前五個網頁都不是，我都懶 得去找究竟排在哪了。 ## 去鋸齒的文字 去銀齒處理是1972在麻薯工學院的Arch itecture Mach i ne Group (后來合并到著名的Med i a Lab)發明的。它的想法是針對低解晰度的彩色顯示，可以用灰階來產生分辨率的「幻覺」。 下面是它看起來的樣子：  注意左邊的正常文字漂亮又銳利，而右邊去鋸齒文字的邊則顯得模糊。如果你斜著看或是退 后一點看，正常文字會因為計算機解晰度有限而出現怪異的「階梯狀」。而去鋸齒的文字看 起來反而比較平滑好看。 所以這就是大家對去鋸齒都很興奮的原因。現在到處都會用去鋸齒，甚至連微軟Windows都 有一個開關可以打開所有系統文字的去鋸齒效果。 那問題呢？如果你嘗試去讀一段去鋸齒的文字，感覺起來就是模糊。事情就是這樣，我也沒 法子。比較一下這兩個段落:  左邊的段落沒有去鋸齒；右邊的則是用Corel PHOTO-PAINT去鋸齒的段落。坦白地說，去鋸 齒的文字看起來就是不好。 終于有人注意到這個問題了 ： M icrosoft Typography group。他們創造了一些非常好的字型， 像是Georgia還有Verdana等等，都是針對容易在屏幕上閱讀而設計的。他們基本上放棄先創 造高解晰度字型再塞入像素格子的作法，而是把像素形成的方格視為先天限制，然后依照限 制設計一個能配合的字型。不過也有些人沒有注意到這件事：Microsoft Reader group使用 了另一種他們稱之為”ClearType”，針對彩色LCD屏幕設計的去鋸齒技術。不過很遺憾的看起 來還是模糊，即使在彩色LCD屏幕上看也一樣。 (在讀者中有繪圖專家生氣抗議之前，我應該要先澄清一下，就標題和圖案而言去鋸齒仍然 是個很好的技術，因為這些應用的整體外觀比維持可閱讀性更重要；另外對照片也很有用， 去鋸齒可以有效地把照片縮成較小的尺寸。） 網絡透明化 遠從第一個網絡開始，提供讓存取遠程資源和本地資源完全相同的程序接口就一直是網絡運 算的「圣杯」。有了它就可以讓網絡變成「透明的」。 網絡透明化有個著名的例子RPC (遠程過程調用），這個系統能讓你呼叫在網絡上另一臺計算 機執行的程序(子程序)，就像這些程序是在本機計算機執行一樣。大家在這上面投入了相當 多的工夫。另一個例子是建立在RPC之上的微軟分布式COM(DCOM)，它可以存取在另一臺計算 機上執行的對象，就像對象是在自己的計算機上執行一樣。 聽起來很合邏輯，對吧？ 錯。 別臺機器資源和本地機器資源在取用上有三個非常大的差異： 1. 可使用性(Availability)， 2. 延遲（Latency),以及 3. 可靠性(Reliability)。 當你要取用別臺機器的資源時，很有可能該機器或是網絡無法使用。其次網絡的速度意味著 需要一段時間去處理該要求，比如你可能是透過28.8kbps的調制解調器執行的。另外對方的 機器可能會當掉，網絡也可能會在通訊過程中斷線（比如貓突然跌倒壓到電話線）。 可靠的軟件在使用網絡時絕對都得考慮這些問題。程序設計界面把這些都隱藏起來，對寫爛 軟件來說真是幫助匪淺。 來個簡單的例子：假設我的軟件要把檔案由一臺計算機復制到另一臺。Windows平臺中傳統 的「透明」作法，是呼叫常用的CopyFile方法，并傳入\SERVER\SHARE\Filename之類的UNC 路徑作為文件名。 如果網絡一切正常，這種寫法就會正常運作。不過如果檔案大小有1 MB又是透過調制解調器 連接網絡，什么問題都可能發生。在傳送這個1 MB的檔案時，整個應用程序都會停住沒有反 應。也不可能顯示進度，因為CopyFile當初設計時就假設一定會是「快」的。如果電話斷線 也不可能續傳。 如果真的想透過網絡傳檔案，用像FtpOpenFile系列函數之類API會比較好。這和在本機復制 檔案是不一樣的，使用上也比較困難。不過這個函數在設計時就考慮到網絡與本機端的程序 設計是不同的，另外它提供掛入(hook)功能可以顯示進度或在網絡不存在或斷線時優雅地處 理，還可以用異步的方式運作。 結論：下次當某人想賣你一套程序設計產品，聲稱可以讓你存取網絡資源有如本機資源 一般，請往反方向全速逃離。