Question

在回到一般性的软件工程话题前，还有几个 fetchmail 的特定经验值得思索。对技术细节不关心的读者完全可以跳过这一节。

rc 控制文件（fetchmail 的配置文件——译者注）的语法包括了一些不会被解析的“噪声”关键字，相比传统配置文件只剩下简洁的“关键字－值”配对，fetchmail 这种类似英语的语法使文件更易读。

这个想法来自于某个深夜，当时我注意到 rc 文件的声明越来越像一个微型指令式语言（这也是为什么我把原先 popclient 中的“server”关键字换成了“poll”）。

在我看来，如果把一个微型指令式语言弄得像英语的话，会更方便人们使用。虽然我很崇尚“让它像语言那样”的设计哲学（正如 Emacs、HTML 以及一些数据库引擎），但我并不痴迷于“让它像英语那样”。

传统程序员倾向于喜欢那种非常简洁、紧凑和没有一点冗余的控制语法。这是计算资源昂贵年代的文化遗留，在当时看来，解析过程应尽可能简单和节省资源。英语大约有 50%的冗余度，很不适宜作为控制语法的模型。

我并不是因此而不喜欢英语语法，相反，提及它正是为了打破传统观念。有了更便宜的计算资源，简洁就不该成为最终目标。对现如今的计算机语言来说，是否便于人类使用要比是否节省计算资源更重要。然而顾虑是有理由的：一方面，解析过程有着复杂性成本——你当然不想让它复杂到容易出错和困惑用户的地步；另一方面，试图让语言拥有类似英语的语法，往往使这个所谓的“英语”严重走形，以至于这种对自然语言的表面模仿并不比传统语法让人更易懂一些（你可以在很多所谓“第四代语言”和商业数据库查询语言中看到恶果）。

16.当你的语言还远不是图灵完备（Turing-complete）的时候，语法糖^[4] 会让你受益良多。

还有一个关于信息隐藏的安全话题。一些 fetchmail 用户要求我改动软件，使 rc 文件的密码能够以加密形式保存，这样能防范一个窥探者轻易看到密码。

我没有答应，因为实际上这并不能增强安全性。任何人如果获取了你的 rc 文件的读权限，都有能力以你的身份运行 fetchmail。此外，如果他们想要你的密码，他们能从 fetchmail 代码中剥离出一个解码器，然后获取密码。

给.fetchmailrc 中的密码加密，只会给那些没有认真思考的人一种安全假象，一般而言：

17.系统的安全性只取决于它所拥有的秘密。谨防虚假的秘密。