2007年12月26日 17:45 [Edit]

perl - ソースが読みにくいには訳がある - そして愛も

camel

Can't agree more!

まつもとゆきひろのハッカーズライフ:第10回 ソースを読もう (2/2) - ITmedia エンタープライズ
このように、ソースコード読解の経験を積むと、読みやすいソースコードと読みにくいソースコードがあることに気がつくと思います。わたしが最悪と思ったのは、(失礼ながら)Perl5のソースコードです。

このPerlのソースコードの読みにくさが、Perlの実装の分化の一番の妨げになってきた。Perlより新しいRubyにYARVが生まれたり、Pythonにあれだけ多彩な実装があるのは、その裏返しと言っていい。Perlにもそういう動きがなかったわけでもないのだが、他の言語のようにうまく行っていないのは、ソースコードの読みにくさが確かにある。Perl5は伏魔殿である。産みの親の手を離れ、育ての親達にゆだねられた今ではおそらくLarryにとってさえ。

にも関わらず、なぜそれでうまく行って来たかといえば、実装は醜くともインターフェイスがきれいだからなのではないか、と私は思う。「どうやっているか」は分からなくとも、「どう頼めば」「何をしてくれる」かというドキュメントが充実しているのである。

例えば、Perlにはperldocといって、ソースコードに説明書を埋め込む機能がある。これはJavaにもjavadoc、Rubyにもriといった形で取り入れられた機能であるが、おかげでCPAN Authorsは半強制的にコードだけではなくドキュメントも書かねばならぬようになった。Perlの世界では、「ソース嫁」ではユーザーは満足してくれない。perldocを読んだだけで使えるようにしておかないと駄目なのだ。

CPANの枠組みは、ドキュメントだけではなくテストも要求する。makeしただけはインストールしてくれず、make testを通らないと駄目なのだ。もちろんテストはやろうと思えばいくらでもズルができるし、cpanシェルにもforceコマンドやnotestコマンドがあるが、ドキュメントやテストを「社会的」に「誘導」しはじめたのは、オープンソースの世界ではPerlが嚆矢といっていいだろう。

理想的なのは、実装もインターフェイスもきれいなこと。しかし、どうしても実装が泥臭くならざるを得ない時には、下の階層でそれを負担する。だからソースコードは、スクリプト(.pl)よりもモジュール(.pm)の方が醜く、そしてモジュール(.pm)よりも本体ソース(.[ch])の方が醜くなりがちで、実際にそうなっている。

いやなことは、下の人がやってくれる。これが、Perlの世界の掟のようだ。

そしてたいていの場合、「下」の方のコードほど、能力的に「上」の人でないと扱えない。Perlのソースコードの醜さは、プログラマーにとっての noblesse oblige の反映ではないか。

とはいえ、泥臭い実装が本当に必要かどうかは、時とともに移ろう。Perlのソースコードの「ワケアリな醜さ」の過半は、今となっては不要な泥臭さなのかも知れない。だからPerl 6というわけでもある。

実装につきものの泥臭さを、どこで担うべきかということに正解はないと思う。でも、私はPerlのありように愛を感じずにはいられない。ちょっと過保護でおかんじみている愛ではあるけれども。

ソースを読む時には、その行間まで読めるようになりたいものだ。

それはとにかく、$KCODEには愛が足りないよね、やっぱ:-)

Dan the Perl Monger


この記事へのトラックバックURL