第九章 源自Fetchmail的更多经验

在我们回到广义的软件工程问题之前，还有几条fetchmail开发中的独特细节需要深思。非技术性的读者可以安心跳过本章。

rc（fetchmail用户配置）文件语法中包含了一些完全不需解析的，可选的“噪音”关键词。与传统“关键词-对应值”匹配关系相比，它们所带来的趋近于英语语法的配置文件更具可读性。

这源自一个深夜的实验，当时我注意到rc文件的配置命令非常像一门微型指令语言。（这也是我把关键字“server”改成“poll”的原因）[1]

在我看来，努力使这个微型指令语言更像英语可以让其更便于使用。现在我虽然支持“让它成为一门语言（make it a language）”的设计流派（诸如Emacs、HTML和很多数据库引擎那样），但是并不热衷于“类英语”的语法。

传统上，程序员们倾向选用简洁紧凑、完全没有冗余的语法。这是计算资源昂贵时期的文化遗留，以致解析过程必须尽可能的简洁廉价。所以如果采用像英语这样有50%冗余的语法建模，在当时显然是很不合时宜的。

这并不是我通常避免使用“类英语”语法的原因。我在这里提及就是为了打破这种观点。有了更廉价的缓存和处理器，简洁就没有必要称为最终的追求了。现在一门语言的人性化远比降低计算成本要重要。

然而，我们仍然有要谨慎为之的原因。其一就是解析过程的复杂度带来的成本——你总不希望这个成本上升到足以滋养错误和迷惑用户吧？另外，让一门语法趋近英语的作法，通常会令其所谓的“英语”走形。以至于对自然语言的表面的模仿会导致如同传统语法一般的混乱。（你可以在很多号称“第四代”的和商业数据库查询语言中看到这种恶果）

Fetchmail的控制语法之所以能避免这些问题，是因为它的语言空间极为有限。它离一门多用途的语言还差得远呢；其所描述的问题也很简单。所以大可不担心穿梭于微小的英语子集和实际控制语言会造成什么迷惑。我觉得这里有一则可以推而广之的经验：

 

16.当你的语言还远不足以达到图灵完备的时候，不妨为语法蘸上一层“糖衣”。[2]

When your language is nowhere near Turing-complete, syntactic sugar can be your friend.

 

另一则经验是有关隐藏的安全性的。一些用户要求我改写软件，以便能对rc文件加密。这样入侵者就不会在无意间看到它们。

我没有照做，因为这并不会带来实际的保护。因为只要有人能获得你rc文件的使用权，他就能和你一样运行fetchmail查看邮件——如果真的想要你的密码，他就可以从fetchmail代码中剥离出必要的解码器。

言而总之，在rc文件中注入密码只是给那些没有深入思考的人一种安全的假象。进而，我们得出通用的规则：

 

17.安全系统的效用只取决于对秘密的保护，谨防伪安全。[3]

A security system is only as secure as its secret. Beware of pseudo-secrets.

 

 

 

 

 

 

译者按：

1.这个关键字后面对应的是邮件服务器名称。计算机中，“Poll”是动词“轮询”的意思，也就是依次向服务器发送报文，收取邮件。而“Server”是名词“服务器”。显然使用“Poll”更符合英语语法。

2.图灵完备：又称图灵完备性。如果一门语言达到“令一切可计算的问题都能计算”的程度就可以说其达到了图灵完备或说具有图灵完备性。

3.“秘密”是指所要隐藏的标的；“安全系统”是指保护这个标的不泄露的手段；“伪安全”是指将标的写入手段的做法。让我们以fetchmail为例，“秘密”就是要保护rc文件，“安全系统”就是密码，把密码写入rc文件显然就是伪安全。