PreviousNextContents


8。続・Fetchmailの教訓

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

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

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

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

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

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

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

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

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

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

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

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

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


PreviousNextContents