Module::Install::Philosophy - Module::Install の背後にある構想
この文書では CPAN::MakeMaker（Module::Install の前身）の背後にあ る個人的な構想を述べる。ここで述べている視点は Brian Ingerson のものな ので、もし興味が無いならこの文書は無視しても構わない。
今日私は、あなたがたに言う。私の友人達よ、例え今は困難と苛立ちに見舞わ れていようとも、私には未だ夢がある。それは Perl モジュールの夢の根底に ある夢だ。
いつの日か、このコミュニティーが立ち上がり、次の信念を本当の意味で実現 するのだと、私はそう夢見ている――我々は次の真実を自明なものとする。す なわち、『全ての Perl 開発者は平等に造られた。』
CGI:: 名前空間の国、砂漠の国、不公正と圧制の暑さで茹だるような国でさ
え、いつの日か自由と公正さのオアシスに変わるのだと、私はそう夢見ている。
私の四つのモジュールが、いつの日か依存モジュールの数によって裁かれるの ではなく、ソースコードの中身によって裁かれるようなアーカイブの中で生き て行くのだと、私はそう夢見ている。
今日、私は夢を見ている。
以上は言うまでもなく偉大なマーティン・ルーサー・キングの不朽の演説のパ ロディーだ（http://web66.coled.umn.edu/new/MLK/MLK.html）。文脈こそ は大きく違うものの、私はこれらに重大な並行性を感じる。
CPAN は不公正から自由ではいられない場所になった。これは或る方向へ高圧的 に指導されたからそうなったのではなくて、我々のコミュニティーが工具の切 れ味を保つのに失敗したからだ。実用性の名の下に小さな決定をたくさん積み 重ねたら、その頂点がこうなったのだ。これは悲しむべき状態である。興味の ある者なら誰であれ、自分の最高の能力を平等に発揮できるような公共の場所 として造られたのだから。
この主張は私の開発者としての個人的な体験が元になっている。最初に自分の Perl モジュールを書いた時、Inline.pm だが、私は何か重要な事をやったのだ と思っていた。でも、どうやって広大な Perl コミュニティーに凹みを作った と思う？
Perl のコミュニティーでは全然知られていなかったので、私の声は遠くまで届
かなかった。何度も XS に詳しいグル達から反応を貰おうとさえしたが、全く
駄目だった。私は modules@perl.org に変な題名のメール
（
http://www.xray.mpe.mpg.de/mailing-lists/modules/2000-08/msg00078.html
）を送ってもみたが、返事が無い。だから純然たる決心と恥知らずな宣伝によっ
て、私はついにその言葉を口に出した。そして世界がそれにとって少しは増し
なものである事を願った。
それからというもの、Inline は賞を取ったし、私には殆どの Perl 警察官に会 える権限が与えられた。でも私はまだその時の痛みを覚えているし、この素敵 な世界にもっと多くの人々を誘いたいと思っている。
経験から学んだ事が一つ。それは Perl のコミュニティーは（Python や Ruby もそうだけど）プログラミングの広大な大洋に落ちた一滴のしずくに過ぎない という事。むこうには Java の巨大なポットがあるし、C の海（sea）がある。 Perl は一番大きい魚ではないかも知れないが、手入れをしたりインチキをした りすれば我々はもっと大きな群れになれるだろう。
これらは私が CPAN とコアモジュールに見る現在の問題点だ。
コアにモジュールを追加する上で最も大きな問題は、追加したとしても長い長 い間ごく微かな Perl ユーザーにしか役立たない事だ。なお悪い事に、良いモ ジュールの開発者はそのコアに追加されたモジュールへの依存をきっと避ける だろう。何故なら、自分のモジュールには 5.8 と同じように 5.005 上でも動 いて欲しいからだ。
この点に関しては CPAN::MakeMaker が役立つはずだ。例えば、Inline.pm を 5.9 のコアに入れる代わりに、今では Inline が對應している全部のバージョ ンの Perl に効率良くインストールする事が出来る。
既存のものと競合するモジュールを書く時は、それに気付いて貰う為にさえ、 少なくとも二倍は良いものにしなければならないのだと知っている。これは悪 い事ではないけど、果して誰もをこの状況に追い込むべきなのか？
例えば、あなたが本当に便利な CGI スクリプトを書いたとしよう。そのスクリ プトはあなたが書いた CGI::Special モジュールを使っている事にしよう。 何故なら CGI.pm には必要な機能が無いからだ。この時、もしそのスクリプ トが一般的に有用で、共有する価値があったとしても、非標準のモジュールに 依存しているという事実は否定的にしか受け入れられないし、その優れた CGI::Special モジュールが一般に受け入れられるようにするのはもっと難 しい。
コアのモジュールは公共的には『優性種』であると仮定される。ある時点のあ るモジュールが本当に優性種であるという事もあるかも知れないが、これのせ いで才能ある人々が別のもっと良いものを繁殖させるのが妨げられているのだ。
もしそんな事が出来るのなら、Perl 自身が動作したりモジュールをインストー ルしたりするものを除いて、我々はコアから全部のモジュールを削除する事だ ろう。勿論モジュールのインストールはとても簡単でなければならないし、必 要ならそれが自動で行われるようにするべきだ。これは簡単に実現可能か？い いや、全然。では不可能？そうじゃない。我々の言語はそれをする上では世界 で最も優れているんだ！
気前の良い事だ。世の中には別の考えを持つ人々も居る。その人々は一度モ ジュールに人気が出たりコアに入ったりしたら、それを修正したり改良したり する事をやめても良いと考えているのだ。ただ個人的に私はこの悪徳に罪悪感 を抱いている。
すると Damian Conway 効果が発生するわけだ。この問題のせいで、多産であり 非常に創造力に富んだ例外的な開発者達が苦しむ事になる。単純に彼等には自 分が書いた全部のコードをメンテナンスする時間は無いからだ。
これらの意見をまとめたのは 2001 年六月の YAPC (Yet Another Perl Conference) の時だった。その時から私はこの社会的な問題を解決する技術的 な方法について考え続けている。
その一つのアイディアとして、ダビングとしての NAPC がある。NAPC は CPAN の代役だ。これは実行時にプリコンパイルされたモジュールをインストールす る為の巨大なシステムで、コアからモジュールを大幅に減らすのが目的である。 NAPC はまだ始まっていない。私はいつかこれをやりたいと思っているが、大き な問題がたくさん残っている。
CPAN::MakeMaker（今では Module::Install）はその一方で、シンプルか つ柔軟性に富んでいる。既存の CPAN プロセスを一切変える事なく共存できる し、新しい機能を今後も追加する事が出来る。CPAN の哲学的な痒みをこれが全 部掻いてくれるわけではないにしても、良い第一歩だ。
これは考察の為の食べ物に過ぎない。ひとつまみの塩をかけて召し上がれ。
Brian Ingerson <INGY@cpan.org>
Copyright (c) 2002. Brian Ingerson. All rights reserved.
This document is free documentation; you can redistribute it and/or modify it under the same terms as Perl itself.