一般的なソフトウェア工学の問題に戻る前に、fetchmail の経験から もう少し教訓を引っぱり出して考察しておこう。

　rc ファイルの構文は、オプションの「ノイズ」キーワードを持っていて、 これはパーサーに完全に無視される。このキーワードのおかげで英語に 似た構文が使えるようになるので、それを全部はぎとってできるような、 従来の無味乾燥なキーワードと値の対応表よりはずっと読みやすくなっている。

　これはそもそも、ある晩遅くにちょっと始めた実験が発端だった。 rc ファイルの宣言が、命令形のミニ言語にずいぶん似てきたのに気がついたのだ （そしてこのせいで、もとの popclient のキーワード「サーバ（server）」 を「チェックせよ（poll）」に変えた）。

　この命令形のミニ言語をもっと英語風にしてみたら、使いやすくなりそうだ と思った。さて、ぼくは Emacs や HTML や各種データベースエンジンに代表される 「なんでも言語化せよ」式デザイン派閥の意識的な急進派ではあるけれど、 通常は「英語っぽい」構文はふつう、あまり好きじゃない。

　伝統的にプログラマは、厳密でコンパクトで冗長性のまったくない 制御構文を好む傾向にあった。これはコンピュータ資源が高価だった時代の 文化的な名残だ。当時は構文解析段階は、できる限り安く単純でなきゃならなかった から。英語は 50％くらい冗長性を持っているので、 当時はすごく不適切なモデルに見えた。

　英語っぽい構文を避けるべき理由としてぼくが挙げたいのはこういうことではない。 ここでこれを挙げたのは、単にそれを却下するためだ。 サイクルやコアが安くなってきたら、無味乾燥がそれ自体で目的化してはならない。 いまでは、言語はコンピュータにとって安あがりになるよりも、 人間にとって便利なほうが大事なのだ。

　でも、慎重になるべきまともな理由はある。一つは複雑さと、 構文解析段階のコストだ —— あんまり複雑にすると、 それ自体がバグのもとになったりユーザの混乱を招いたりしかねない。 別の理由として、言語の構文を英語っぽくしようとすると、 しばしばその言語の使う「英語」はとんでもなく歪んだ代物になってしまい、 これが高じると、そういうわざとらしい自然言語との類似は伝統的な構文と 同じくらい混乱をまねくことになる（これはいろんな通称 4GL や商業データベースキュエリー言語で見かける）。

　Fetchmail の制御構文は、どうやらこういう問題を免れている。 それは、言語ドメインがすごく制限されているからだ。汎用言語にはほど遠い。 それが表現していることは、とにかく大して複雑ではないので、 英語の小さなサブセットと実際の制御言語の間を行き来するのに、 精神的な混乱を起こす可能性があまりない。 ここにはもっと広い教訓があるかもしれない。

16. 自分の言語がチューリング的完成からほど遠い場合には、構文上の甘さを許すといろいろ楽になるかもね。

　別の教訓は、隠すことでセキュリティを高めるという点についてのものだった。 Fetchmail ユーザの一部は、ソフトの仕様を変えて、パスワードを暗号化して rc ファイルに保存するようにしてくれと要求してきた。 のぞき屋たちが気軽にそれをのぞいたりできないようにしてほしいから、 と言って。

　これはやらなかった。これでは実は、セキュリティはぜんぜん高まらないからだ。 rc ファイルを読む許可を与えられている人間なら、だれでも fetchmail をどのみちあなたと同じように好き勝手に動かせてしまうんだから —— そしてそいつがあなたのパスワード目当てなら、fetchmail のコードそのものから 必要なデコーダをぬきだして、ファイルを解読して盗むことができてしまう。

　だから .fetchmailrc パスワード暗号化なんかしても、 ものごとをつきつめて考えない人たちに、 セキュリティが高まったかのようなまちがった幻想を与えるだけだ。 ここでの一般原則は以下の通り：

17. セキュリティシステムのセキュリティは、 そこで使われてる秘密の安全性にかかっている。 見かけだけの秘密は要注意。