半分だけ同意。

304 Not Modified: プログラマの美意識
私にとって美しいプログラムとは、シンプルなプログラムのことです。

なぜ半分だけ、かというと、美しくない状況をより美しくすることがプログラムの使命であるならば、結果としてソースコードが美しくならないことも往々にしてあるから。

もっと身も蓋もない言い方をすると、この世の穢れをプログラムが背負う事もまたあるのだということ。

このことは、特にAPIを提供するソースを書くときに顕著だ。こういったプログラムに求められるのは、APIが美しいことであって、ソースコードそのものが美しいことではない。そこでは、さまざまな泥臭いことはAPIを提供するプログラムがかぶることで、APIのユーザーは醜いものを気にせずにプログラムできるようになる。

実装が美しいけどツカエないプログラムと、実装は醜いがツカエるプログラムとどちらがよいかといえば、後者の方に決まっている。もちろん実装も美しくかつツカエるプログラムというのもありで、プログラマーは皆それを目指しているのだけど、プログラマー側の美と、ユーザー側の美と、どちらかの選択を迫られたら、迷わず後者をとるのが私にとっての美しいプログラマーの定義だ。

これはまた、Perlの哲学でもある。Perlできれいなプログラムを書く事はいくらでもできるし実際そうされている。少なくとも今時のアルファギークと呼ばれる人たちの美的感覚は鋭い。しかし、Perlはプログラムを醜く書いた事を罰したりもしない。それがやむにやまれぬ場合があることを知悉しているからだ。

その結果、Perlそのもののソースコードはなかなかの伏魔殿となっている。たとえばregexpを処理する関数は、それだけで3000行ほどある。これは美しいソースコードの対極にある。しかしそのおかげでPerlユーザーは、強力かつ美しいregexpを手に入れることが出来た。

Perl本体のソースコードは「他の美しさのために自らは穢れる」の極北であるが、大御所モジュールの多くがこのポリシーに「殉じて」いる。CGI.pmのソースというのはほんとすさまじいものだが、おかげでそれがGETだろうがPOSTだろうが、application/x-www-form-urlencodedだろうがmultipart/form-dataだろうが、普通にプロセスとして実行されようがmod_perlやFastCGIから「実行」されようが、ユーザーは常に$q->param("key")で入力を受け取れる。いや。OOがいやだというのであれば、param("key")だっていいのだ。そのためにCGI.pmが負っている「穢れ」は、ソースが読めるものであれば「全米が泣いた」クラスであることが理解できるだろう。

もちろん同様の苦労は、Jcode.pmにもEncode.pmにもある。特にEncode.pmの場合、負っている「穢れ」は、ソースコードだけではない。肝心の文字コード表の並びをどうするかというのは、プログラミングに留まらない「政治的」な問題でもある。例えばShift_JISやEUC-JPなどの日本語文字コードの場合、ASCII部分はノータッチという実装は、日本のプログラマーにとっては常識でも、欧米、特に欧州のプログラマーにとっては非常識で美しくなくそして「仕様違反」に映る。メンテナーとして最も楽なのは、Unicode Consortiumが公開した(正確にはしていた)対応表を忠実に実装することだったが、それではツカエないものになることは明白だった。結論は、Encodeの方で泥をかぶることだった。この結論を提案し、関係者を納得させるのはプログラミングよりはるかに大変だったが、これは正しい選択だったと自身をもって言える。

美しさの追求は、プログラマーとしては欠かせない資質だと思う。しかし人のために自分の美しさを譲ることができるのもまた、プログラマー、それもプロのプログラマーに求められる条件なのではないか。

Dan the Tainted Coder