405    这是计算资源昂贵时期的文化遗留，以致解析过程必须尽可能的简洁廉价。

406    所以如果采用像英语这样有50%冗余的语法建模，在当时显然是很不合时宜的。

407    这并不是我通常避免使用´类英语”语法的原因。

408    我在这里提及就是为了打破这种观点。

409    有了更廉价的缓存和处理器，简洁就没有必要称为最终的追求了。

410    现在一门语言的人性化远比降低计算成本要重要。

411    然而，我们仍然有要谨慎为之的原因。

412    其一就是解析过程的复杂度带来的成本你总不希望这个成本上升到足以滋养错误和迷惑用户吧？

413    另外，让一门语法趋近英语的作法，通常会令其所谓的´英语”走形。

414    以至于对自然语言的表面的模仿会导致如同传统语法一般的混乱。

415    （你可以在很多号称´第四代”的和商业数据库查询语言中看到这种恶果）

416    Fetchmail的控制语法之所以能避免这些问题，是因为它的语言空间极为有限。

417    它离一门多用途的语言还差得远呢；其所描述的问题也很简单。

418    所以大可不担心穿梭于微小的英语子集和实际控制语言会造成什么迷惑。

419    我觉得这里有一则可以推而广之的经验：