[ささだくんの日記|http://www.namikilab.tuat.ac.jp/~sasada/diary/200601.html#d19]に反応して。\\ 言語仕様としてのPerlとRubyの比較とかは置いておくとして，CPANモジュールとそれに関わるツールという点でPerlの良いところを並べてみます。 #CPANという枠組そのもの #CPAN.pmによりインストールプロセス・パッケージングの共通化がされていること #CPANに集約されていることで，その情報を２次的に使ったツールが色々あること #perldoc, CPAN Searchなどで同じ見た目でマニュアルが読めること #podの書き方が（ある程度）統一されていて，どこから読めば良いかが分かりやすいこと !!1. CPANという枠組みそのもの 2. CPAN.pmによる共通化 1. 2.はドキュメントうんぬんとは関係ないけれど，一元化・共通化されていることは非常に重要です。 一元化されていることにより2. 3. 4. のツールが使え，魅力的なツールが使えるという理由で開発者がCPANにアップロードしようという気になる，という好循環を生み出している訳です。 !!3. CPANをサポートする各種ツール DBIを例にして，Webで動いてるツールを列挙すると・・・ !CPAN Search [http://search.cpan.org/~timb/DBI-1.50/]でファイルの一覧を見て， [http://search.cpan.org/~timb/DBI-1.50/DBI.pm]でドキュメントを先に読む。ソースも読める。 それでCPAN.pm使って（or パッケージ管理ツールで）インストールしたり直接ダウンロードしたり。 [http://search.cpan.org/recent]や，そのRSSで更新モジュールを眺めたりもできる。 !Kobesearch モジュール検索はもう一つバージョンがある（[http://kobesearch.cpan.org/htdocs/faqs/cpan-search.html]）。 DBIモジュールなら[http://cpan.uwinnipeg.ca/dist/DBI], [http://cpan.uwinnipeg.ca/htdocs/DBI/DBI.html], [http://cpan.uwinnipeg.ca/htdocs/DBI/DBI.pm.html]となる。 個人的にはこっちの方が好み。 !CPAN Testers [http://testers.cpan.org/show/DBI.html]でビルドテストの結果が見れる。 Test::Reporterモジュールを使うと，ユーザの環境でテストした結果が報告できる・・・らしい。 詳しくは知らない。 !RT CPAN 各モジュールに対するバグ追跡もある。[http://rt.cpan.org/Public/Dist/Display.html?Name=DBI] モジュールによっては（Catalystとか）作者側が別に用意してたりもするけど。 !CPANTS - CPAN Testing Service [http://cpants.dev.zsi.at/dist/DBI]の[detail|http://cpants.dev.zsi.at/kwalitee/31423]できちんと作法を守ったモジュールになってるか確認できる。 ビルドまではしないので「決められたファイルがちゃんとあるか」とか「use strictしてる？」とか「podを"確認するテスト"がちゃんとあるか」（実際に確認するのではない）とかしかしないけど。 「他のCPANモジュールのprereqに入ってるか」は面白いと思う。 !ユーザコミュニティサポート [http://cpanratings.perl.org/dist/DBI]にレビュー， [http://www.cpanforum.com/dist/DBI]にフォーラムがある。 [http://annocpan.org/~TIMB/DBI-1.50/DBI.pm]はpodに対してコメントが付けられて面白い。 日本では[MFPM - My Favorite Perl Modules|http://mfpm.blogdb.jp/app/view/DBI/]とかある。 これだけのツールが'すべてのCPANモジュール'で使えるのです。 CPANという扱いやすくパッケージングされたモジュールが集積されていて，公開されていて，それに対して（あんまり使いたくない言葉だけど）web 2.0的なmashupが行われているとも言えるでしょう。 ちなみに，日本語でのドキュメントについては[http://perldoc.jp/]とか[http://cpan.jp/]のように頑張っている人はいるんだけど，本家CPANのような統一された美しさが無いのが残念。 まあ，CPANモジュールはものによって更新頻度がすごいことになる（一時期のCatalystとか）ので，英語のドキュメントを読むのが基本です。 !!4. 同じ表示形式でモジュールのドキュメントが読めること そして，このうちの基本ともいえるCPAN Search (Kobesearchの方が好みだけど)で，すべてのCPANモジュールについて同じ表示形式でドキュメントが読めます。 さらに，CPAN searchやKobesearchでは他のツール（におけるそのモジュールのページ）にリンク張ってあったりして便利になってます。 !!5. 各モジュールのドキュメントの書き方が統一されていること いくつかモジュールのドキュメントを見ると分かると思いますが，podでは原則として *NAME *VERSION *SYNOPSIS *DESCRIPTION *（メソッドor関数の詳細など） *SEE ALSO *AUTHOR *COPYRIGHT と，（省略されたりすることもあるけど）大体同じ順番で書かれています。 （どっかで「こうしようね」ってあったはずなんだけど，ソースを失念） 4. で見た目が同じになっているだけでなく，文書構造自体も大体同じようになっている訳です。 4.と5.により，ある程度モジュールのドキュメントを読むのに慣れれば，新しいモジュールのドキュメントを読むのが容易になっています。 !!まとめ－Perl/CPANの良いところ *モジュールが一箇所に集まっている←便利だし魅力的だからモジュールが集まる *ドキュメントが「同じように」読めるので分かりやすい ということで。