資訊科學中三個錯誤的想法 Three Wrong Ideas From Computer Science

作者:周思博 (Joel Spolsky)
譯:Paul May 梅普華
Tuesday, August 22, 2000
屬於 Joel on Software, https://www.joelonsoftware.com/2000/08/22/three-wrong-ideas-from-computer-science/

我並不是要潑大家冷水,不過坦白講資訊科學裡有三個重要的想法是錯的,而且大家也開始注意到了..為了你自己好請忽略它們。

我相信還有其他的,不過這是最讓我感冒的三個:

  1. 搜尋的困難之處在於找到足夠的結果,
  2. 反鋸齒(anti-aliased)的文字比較好看,還有
  3. 網路軟體應該讓網路資源的行為和本地資源一模一樣。

嗯,我只能說,

  1. 錯,
  2. 錯,
  3. 全部都錯!

讓我們來個簡短的巡禮。

搜尋

大部份搜尋的學術研究都一定會被類似的問題所困擾:比如「如果搜尋"car",可是想要的文件內用的卻是"automobile",這時要怎麼處理?」

事實上極大量的學術研究在探討多形態(stemming)之類的概念,在這個概念下你所搜尋的字會被去結合(de-conjugated),所以用"searching"來搜尋時,也會找到內含"searched"或"sought"的文件。

所以當 Altavista 這種大型 Internet 搜尋引擎剛出現時,都在宣傳他們可以找到很多很多的結果。用Altavista搜尋Joel on Software會得到1,033,555個網頁。這種結果當然是無用的,目前已知 Internet 大約有十億個網頁(譯註:當時是西元2000年),Altavista 把十億個網頁縮減成一百萬個,對我來說是完全沒有意義的。

搜尋真正的問題在於如何將結果排序。不過要為電腦科學家辯護一下,除非有人開始拿 Internet 這麼巨大的資料來做索引,否則根本不會有人注意到這一點。

不過還是有人注意到了。Google 的 Larry Page 和 Sergey Brin 瞭解到,以正確的順序呈現網頁 ranking,比把所有可能的網頁都抓來要重要多了。他們的PageRank演算法是個很好的方法,可以對很龐大的結果進行排序,讓你所要的結果很可能列在前十項。事實上用 Google搜尋 Joel on Software就會看到它出現在第一項。用 Altavista 搜連前五個網頁都不是,我都懶得去找究竟排在哪了。

反鋸齒的文字

反鋸齒處理是1972在麻省理工學院的Architecture Machine Group(後來合併到著名的Media Lab)發明的。它的想法是針對低解晰度的彩色顯示,可以用灰階來產生解析度的「幻覺」。下面是它看起來的樣子:

Antialiasing.gif

注意左邊的正常文字漂亮又銳利,而右邊反鋸齒文字的邊則顯得模糊。如果你斜著看或是退後一點看,正常文字會因為電腦解晰度有限而出現怪異的「階梯狀」。而反鋸齒的文字看起來反而比較平滑好看。

所以這就是大家對反鋸齒都很興奮的原因。現在到處都會用反鋸齒,甚至連微軟Windows都有一個開關可以打開所有系統文字的反鋸齒效果。

那問題呢?如果你嘗試去讀一段反鋸齒的文字,感覺起來就是模糊。事情就是這樣,我也沒法子。比較一下這兩個段落:

Antialised_Paragraph.gif

左邊的段落沒有反鋸齒;右邊的則是用Corel PHOTO-PAINT反鋸齒的段落。坦白地說,反鋸齒的文字看起來就是不好

終於有人注意到這個問題了:Microsoft Typography group。他們創造了一些非常好的字型,像是Georgia還有Verdana等等,都是針對容易在螢幕上閱讀而設計的。他們基本上放棄先創造高解晰度字型再塞入像素格子的作法,而是把像素形成的方格視為先天限制,然後依照限制設計一個能配合的字型。不過也有些人沒有注意到這件事:Microsoft Reader group 使用了另一種他們稱之為 "ClearType",針對彩色LCD螢幕設計的反鋸齒技術。不過很遺憾的看起來還是模糊,即使在彩色LCD螢幕上看也一樣。

(在讀者中有繪圖專家生氣抗議之前,我應該要先澄清一下,就標題和圖案而言反鋸齒仍然是個很好的技術,因為這些應用的整體外觀比維持可閱讀性更重要;另外對照片也很有用,反鋸齒可以有效地把照片縮成較小的尺寸。)

網路透通性(Network Transparency)

遠從第一個網路開始,提供讓存取遠端資源和本地資源完全相同的程式介面就一直是網路運算的「聖杯」。有了它就可以讓網路變成「透明的」。

網路透通性有個著名的例子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)功能可以顯示進度或在網路不存在或斷線時優雅地處理,還可以用非同步的方式運作。

結論:下次當某人想賣你一套程式設計產品,聲稱可以讓你存取網路資源有如本機資源一般,請往反方向全速逃離。

這些網頁的內容為表達個人意見。
All contents Copyright © 1999-2006 by Joel Spolsky. All Rights Reserved.