# 十七、源于计算机学科的三个错误思想 我并不是要泼大家冷水，不过坦白讲信息科学里有三个重要的想法是错的，而且大家也开始 注意到了 ..为了你自己好请忽略它们。 我相信还有其他的，不过这是最让我感冒的三个： 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)功能可以显示进度或在网络不存在或断线时优雅地处 理，还可以用异步的方式运作。 结论：下次当某人想卖你一套程序设计产品，声称可以让你存取网络资源有如本机资源 一般，请往反方向全速逃离。