Perl.com 
 出版元: Perl.com http://www.perl.com/pub/a/2004/01/09/survey.html
コード例を印刷する場合に問題があれば、ここを参照して下さい。

 

Perl の現状

Adam Turoff 著

2004 年 1 月 9 日

同僚が、最近、Perl の未来について尋ねました。特に、彼は、今日最も人気のある 2 つのプラットフォームである .NET と Java に対抗できるトリックを何か隠しもっているのかどうかを気にかけていたのです。ためらうことなく、私は、Perl に未来があるかを尋ねられた時にこの間ずっと使っていた答えを繰り返しました。

Perl が有効で、優れた働きをしていることは確かです。Perl 6 の開発チームは、次世代の Perl 言語を定義するため、精一杯の仕事をしています。別のチームの開発者は、Perl 6 の次世代の実行時エンジンである Parrot で精一杯の仕事をしています。Parrot は、Perl 6 のような動的な言語をサポートするだけでなく、Python や Ruby などもサポートするようにデザインされています。Perl 6 は、既存の Perl 5 コードの透過的な移行もサポートしています。

そして、私は、愛想よく、次のように補足しました。

Fotango は、Parrot 上で Perl 5.10 を再実装する Ponie の作業をしている開発者の 1 人である Arthur Bergman のスポンサーになっています。

多くの場合、"Perl に未来はあるか" という質問には、この答えで十分です。

しかしながら、同僚は、既に、Perl 6 と Parrot について知っていました。Perl 6 は、約 3 年半前に、大量のファンファーレとともにアナウンスされたからです。2001 年のエイプリルフールのジョークとしてアナウンスされた Parrot プロジェクトは、今では、実際のオープンソースプロジェクトとして 2 才になります。Parrot は驚くほどの進展を見せましたが、製品として使用する用意はまだできていませんし、まもなく登場するというわけでもないでしょう。Parrot が掲げる短期的な大きな目標は、Python のバイトコードを、標準の CPython 実装よりも高速に実行することです。しかも、それを 2004 年 7 月の Open source Convention までに行なうことです。それまでに行なうべき作業は、かなり多くあります。Parrot を、マイルストーンから、例えば Perl のようなものを置き換えて使えるようなものにするには、更に多くの作業が必要です。

Related Reading

Perl 6 Essentials

Perl 6 Essentials
By Allison Randal, Dan Sugalski, Leopold Tötsch

Table of Contents
Index
Sample Chapter

Read Online--Safari Search this book on Safari:
 

Code Fragments only

それでは、Perl 6 と Parrot の壮大な計画を別にして、Perl に未来は本当にあるのでしょうか。

Perl 開発の現状

Perl 6 と Parrot は、未来を表わすものではなく、むしろ、長期的な保険のポリシーです。Perl 6 がアナウンスされた時、Perl 5 の実装は、既に、約 7 才でした。コアとなる開発者は、Perl 5 の移植者から離れ、後継は現れませんでした。(当時、そのことは知られていませんでしたが、ありがたいことに、それが一時的な中休みだったことが分かりました。) ソースコードは非常に複雑で、新しい開発者にとっては気の遠くなるようなものです。実質上、誰もコアインタープリターをハックできなければ、Perl をオープンソースプロジェクトとして、これからの 10 年、20 年に渡って維持できるかどうかは明らかではありませんでしたし、それは今も変わっていません。

2000 年に、Larry Wall は、Perl 6 を、Perl が実際上意味のあるものであり続けるための、そして、Perl の世界内を流れ続ける理念であり続けるための手段と見ていました。当時の恐れは、きわめて明白なものでした。新しく登場する多くのハッカーが Perl ではなく Java や Python の開発をするなら、何年にも渡って費やし、あこがれてきたスキルは、たちどころに役に立たないものになり、文字通り、無価値なものになってしまいます。更に、13 年 (今では 16 年) にも渡る動作する Perl コードとの後方互換性は、Perl が新しい要求に応えることのできた気軽さに制限を加え始めました。論理的に極端なことを言ってしまえば、こうした要因のすべては、Perl にとって逆風として作用し、Perl を、明日の問題を効率的に解決できない昨日の言語にしてしまうものなのです。

Perl 6 の計画は、言語の新しい実装を提供するだけでなく、誰でも拡張可能な新しい言語のデザインを提供するものでもあります。これによって、言語としてそしてコンパイラー/インタープリターとしての Perl のメンテナンスと拡張ができ、それに関心のある人の数を増やすことができるでしょう。新たに出発することによって、Perl の開発者が、当時そして現在の Perl 5 実装では現実的ではなかっただけの新しい大胆な方向にかじを切るのを助けることになるでしょう。

今日、そして、過去 3 年に渡って、Perl 開発コミュニティーは、現実の人々やビジネスが現在直面している問題を解決する革新的なソフトウェアを書くことに非常に積極的です。しかしながら、その革新とインスピレーションは、Perl がそうであると考えられているほど完全なものではありません。私達は、生産の新しい波を駆り立てる新しい言語と実装を見るのではなく、私達すべてが知っていて愛している言語である Perl 5 で直ちに利用できるコードのある CPAN で利用できるライブラリーとモジュールにおける革新を見ているのです。

非常に現実的な意味で、Perl 6 プロジェクトは、既に、その本当の目標を達成しています。Perl が実際上意味のあるものであり、興味深いものであり続けるための、そして、Perl のコミュニティー内を流れ続ける生産性であり続けることです。

このことは、Perl の未来にとって、何を意味しているのでしょうか。何よりもまず、Perl 5 の開発は、Perl 6 と Parrot と並行して進んでいます。Perl 5 の開発には、現在、アクティブな 5 つの分岐があります。メイン系列は、Perl 5.8.x で、有効で、優れた働きをしています。Jarkko Hietaniemi は、今年の初めに、Perl 5.8.0 のメンテナンスアップグレードとして、Perl 5.8.1 をリリースし、パッチの役割を、現在 Perl 5.8.3 の構築作業を行なっている Nick Clark に引き継ぎました。昨年 10 月には、Hugo van der Sanden が、Perl 5.10 につながる開発系列である Perl 5.9.0 の最初のスナップショットをリリースしました。そして、昨年夏、Fotango は、Arthur Bergman が、現在の Perl 5 エンジンではなく、Parrot 上で動作する Perl 5.10 ポートである Ponie の作業していることをアナウンスしました。Perl 5.12 が、新しい実装の上で動作する最初の製品リリースとなるかもしれません。

互換性の問題のため、もっと古いバージョンの Perl を使っている開発者のため、Rafael Garcia-Suarez は、Perl 5.6.1 のアップデートである Perl 5.6.2 の作業を行なっています。これは、最近のオペレーティングシステムとコンパイラーのリリースのサポートを追加するものです。Leon Brocard は、Perl 5.005_04 に対する同様のアップデートを行なう作業を続けています。

Perl は、どこに行くのでしょうか。Perl は前進していますが、それは、並行した多数の方向に向かっているのです。日常の開発者にとっては、仕事を行なう上で、3 つの Perl リリースが役立つでしょう。5.8.x と 5.6.x、そしてどうしても必要な場合には、5.005_0x です。Perl 自身を開発する Perl 5 の移植者の場合、持ち場が 5.8.x と 5.9.x であることは共通認識です。最先端の開発者の場合、Parrot に関して行なうべきことが数多くあります。真の最先端のため、Larry と彼を補佐する人達は、Perl 6 言語のデザインのもっと優れた核心についての検討を続けています。

ここまで、言語やプラットフォームとしての Perl の開発が、どこに行くのかを説明しました。しかし、本当に興味深いことは、言語の問題ではなく、Perl がどのように使われてるかなのです。

Perl 使用の現状

在野で Perl がどのように使われているかをかいま見る 1 つの方法は、CPAN を見ることです。私は、最近、モジュールリスト (www.cpan.org/modules/01modules.index.html) を眺め、モジュール配布版の最新リリースがどの年にリリースされたのかをカウントしました。この統計は完全なものではありませんが、現在利用できる CPAN 配布版の年齢のかなり正確な近似値が分かります。

        1995:   30 ( 0.51%)
        1996:   35 ( 0.59%)
        1997:   68 ( 1.16%)
        1998:  189 ( 3.21%)
        1999:  287 ( 4.88%)
        2000:  387 ( 6.58%)
        2001:  708 (12.03%)
        2002: 1268 (21.55%)
        2003: 2907 (49.40%)
        cpan: 5885 (100.00%)

おもしろいことに、CPAN にある配布版の約半数が、2003 年に作られたか、更新されたものです。もう少し分析を進めると、これらの配布版の約 85% が、2000 年 7 月に Perl 6 がアナウンスされて以降に作られたか、更新されたものだということです。Perl を使った開発に対する関心が衰えていないことは、明らかです。ここから言えることは、CPAN のアクティビティーから測る限り、Perl の開発は、まったく健全だということです。

CPAN の "新鮮さ" を見ても、Perl に関する物語全体を語っていることにはなりません。それは、Perl 開発者が積極的に CPAN にコードをリリースしていることを示しているだけだからです。こうしたアップデートの多くは、新しく、興味深いモジュールであるか、私達が毎日使用するモジュールに新しい機能を追加したり、モジュールのバグフィックスのためのアップデートです。モジュールの中には、何年もアップデートされていないにも関わらず、安定していて、非常に役立つものもあります。しかし、モジュールの多くは、古く、時代遅れとなったり、ジョークモジュールであったり、放棄されたものだったりするのです。

悲観論者は、CPAN の中に、放棄された配布版やバグに満ちたソフトウェア、ジョークモジュールや開発の初期段階にある ("実用" には程遠いことが確かな) パッケージを見ることでしょう。楽観論者は、CPAN の中に、驚くほど役立つ幾つかのモジュールを見て、CPAN の片すみに潜んでいるあまり役立たないモジュールを無視することでしょう。

どちらの見方が正しいのでしょうか。モジュールリストを見ると、ごく僅かなモジュールだけが、Acme ネームスペースにジョークとして登録されているにすぎません。つまり、5800 を超える配布版のうちの約 85、CPAN にあるモジュールの 2% 未満です。もちろん、Acme ネームスペース以外にも、ジョークモジュールはあります。Lingua::Perligata::RomanaLingua::Atinlay::Igpay などです。けれども、CPAN モジュールとしてリリースされているジョークの数は、CPAN 全体と比べると、ごく少数です。

しかし、実際には、CPAN のどれだけが役立つのでしょうか。それは、解決しようとしている問題の種類によります。CPAN のおよそ 82% にあたる、過去 3 年以内にリリースされたコードだけが考察に値すると仮定しましょう。更に、Acme ネームスペース内のすべては無視してよいことと、ジョークモジュールの総数は Acme モジュールの数の 2 倍にすぎないと仮定しましょう。CPAN の更に 3-4% を無視することによって、検討しなければならないのは、約 78%、4,000 を超える配布版ということになります。

このコードのうち、どれだけが製品品質なのでしょうか。これは、実際には、答えるのが難しい問題です。こうしたモジュールは、気が遠くなるほど様々な範囲の問題ドメインに渡っているからです。次のものが含まれますが、それに限られるわけではありません。

... これは、現在、CPAN で利用できる配布版のごく限られた種類の不完全なサンプルにすぎません。何千とは言わないまでも、何百もの CPAN モジュールが、通常直面する問題を解決するため、日々、使われていると言うことで満足することにしましょう。

それでは、それは、ともかくも、製品品質の本当の定義ではないのでしょうか。

Perl 使用の別の現状

Larry が 1998 年の Perl Conference での 2 回目のキーノート講演 (www.perl.com/pub/a/1998/08/show/onion.html) で述べたように、Perl コミュニティーは、たまねぎに似ています。重要な部分は、小さな中心部ではなく、むしろ、かたまりのほとんどと成長のすべてがある外側のもっと大きな層です。そのため、Perl の本当の現状は、インタープリターの開発や CPAN の成長にあるのではなく、日々、Perl がどのように使われているのかにあるのです。

何故、Perl を毎日使うのでしょうか。Perl は、小さな問題と大きな問題の両方を解決するため、伸縮自在だからです。C や C++、Java などの言語とは違って、Perl を使えば、大規模なアプリケーションやシステムを構築する能力を犠牲にすることなく、小さな、些細な問題を解決するコードをすばやく簡単に書くことができます。大規模プロジェクトで使用するスキルやツールは、小さなプログラムを書く時にも利用できます。

小さな問題でのプログラミング

次の例は、よくあるものです。O'Reilly Perl リソースページを見て、そのページにあるリンクをすべて見つけたいとしましょう。このプログラムは、2 つのモジュールをロードすることから始まります。ページを取得する LWP::Simple と、リンクをすべて抽出する HTML::LinkExtor です。

        #!/usr/bin/perl -w

        use strict;
        use LWP::Simple;
        use HTML::LinkExtor;

        my $ext = new HTML::LinkExtor;
        $ext->parse(get("http://perl.oreilly.com/"));
        my @links = $ext->links();

この時点で、ウェブスパイダーやおそらくスクリーンスクレーパーの始まりにいます。正規表現を幾つかと、grepmap あるいは foreach などの 1 組のリスト操作を使えば、このリンクのリストを、O'Reilly の書籍カタログである Safari や Perl.com にある新しい記事へのリンクのリストに切り縮めることができます。もう 1 組の行を追加すれば、(DBIDB_FileGDBM あるいはその他の何らかの永続的データ保存を使って) こうしたリンクをデータベースに保存することもできるでしょう。

私は、何年にも渡って、こうしたプログラムを数多く書いてきました (そして投げ捨ててきました)。それらは、いつでも書くのが容易で、コードは 1 ページに満たない場合がほとんどです。それは、Perl と CPAN が提供する機能について雄弁に物語っています。それは、1 人のプログラマーが、数分で、僅かな努力をするだけで、どんなに多くのことを成し遂げることができるかについて雄弁に物語っています。

けれども、最も重要な教訓は、Perl を使えば、アプリケーションと大規模なシステムを書くのにも、小さなスクリプトを書いてハックを行なうのにも、同じツールが利用できるということです。ありふれた問題をすばやく簡単に解決できるだけでなく、1 セットのツールとスキルを使って、幅広い問題が解決できます。更に、同じツールを使うことによって、比較的大きなシステムでも、すばやいハックを働かせることができるのです。

大きな問題でのプログラミング

もちろん、Perl プログラムがすばやいハックを超えて、スケールアップできると主張することと、実際に、Perl を使って、大規模システムを構築するということは別問題です。Perl サクセスストーリーアーカイブ (perl.oreilly.com/news/success_stories.html) は、こうした努力を詳細に論じています。それには、多くの大規模システム、ボリュームの大きなシステム、基幹業務のアプリケーションが含まれています。

次に、Perl Conference や Perl 関連の様々なメーリングリストで注目を集める際立ったシステムがあります。例えば、インターネット最大の小売業者である Amazon.com は、ウェブサイトの一部に HTML::Mason を使っています。Mason を使う 50 あまりの別のサイトが、www.masonhq.org で紹介されています (www.masonhq.com/about/sites.html)。それには、Salon.com、AvantGo や DynDNS が含まれています。

Morgan Stanley は、もう 1 つの Perl のビッグユーザーです。今をさる 2001 年に、W. Phillip Moore は、Morgan Stanley にあるテクノロジーインフラストラクチャーに対して、Perl と Linux のどこが適しているかを語っています。もっと最近では、Merijn Broeren は、Morgan Stanley が、そこにある 9,000 ものコンピューターを無停止で動かしておくために、どれほど Perl に依存しているか、そして、世界中で使われている様々な種類のアプリケーションにどれほど Perl が利用されているかを詳細に述べています (conferences.oreillynet.com/cs/os2003/view/e_sess/4293)。

パフォーマンスの高いインターネット広告のプロバイダーである ValueClick は、別のやり方で、Perl を活用しています。毎日、ValueClick は、出版業者のウェブサイトで、ターゲットのある無数のバナー広告のサービスをしています。どの広告をどこに送るかを選択するプロセスは非常に正確で、洗練された Perl のコードがそれを処理しています。これらの広告がどの程度効率的かを分析するには、大量のログデータを切り刻む必要があります。ValueClick が、ここでも、Perl を使っていることは、驚くことではありません。

Ticketmaster は、世界中の少なくとも 20 の国で、スポーツや娯楽イベントのチケットを販売しています。1 年間で、Ticketmaster は、世界中で、8,000 万枚を超えるチケットを販売します。最近では、Ticketmaster は、1 日のうちに 100 万枚のチケットを販売しました。そのうち、約半数のチケットがウェブ上で売られました。そして、Ticketmaster のウェブサイトは、ほとんどすべてが Perl で書かれているのです。

ここで紹介したのは、大規模で重要な製品のために Perl を使う企業のほんの一部にすぎません。周囲を見渡してみれば、これに似たもっと多くのストーリーが見つかるはずです。何年もの間、私は、ウェブベースの何らかの製品やサービスを作った企業で働いてきました。それらは、もっぱら Perl を使って構築したものです。その数は、数社にとどまりません。こうした製品の中には、年間収入が 1,000 万ドルを超えるものに責任があるものもあります。

Perl が単なるハックのためのものではないことは、これで明らかでしょう。

Perl 使用の新たな現状

多くの企業が Perl を使って、顧客に売ることのできる独自の製品とインターネットベースのサービスを構築しています。ますます多くの企業が Perl を使って、内部システムの実行を維持し、ありふれたプロセスを自動化することにより、金の節約をしています。

今日、人々が Perl を使う新しいやり方は、オープンソースビジネスです。Best Practical や Kineticode のような企業は、Perl を使って製品を構築し、トレーニングやサポート契約、カスタム開発から金を稼いでいます。そうした製品はオープンソースで、自由に利用でき、簡単に拡張できます。けれども、こうした企業が利益を得て、これらのオープンソース製品の開発を支えるのに十分なアドオンサービスへの需要があるのです。

Best Practical Solutions (www.bestpractical.com) は、Request Tracker を開発しています。これは、もっと一般的に、RT (www.bestpractical.com/rt) として知られているものです。RT は、問題追跡システムで、これを使えば、チームは、アクティビティーを調整して、ユーザーのリクエストやバグフィックスを管理し、個々のタスクに費やしたアクションを追跡することができます。オープンソースプロジェクトとして、RT は、1996 年から開発されてきました。そして今では、何千もの企業ユーザーを獲得しています。それらは、Best Practical の感謝ページ (www.bestpractical.com/rt/praise.html) にリストされた企業が含まれています。現在、RT は、Perl 開発のバグ追跡 (rt.perl.org/perlbug) と CPAN のモジュール開発 (rt.cpan.org) に力を注いでいます。多くの企業が、RT 内に保持する情報に依存しています。それは、時には、1 日につき 1000 の問題、年間で、追跡し、解決しなければならない 300,000 の問題に及びます。

Kineticode (www.kineticode.com) は、Bricolage 内容管理システム (www.bricolage.cc) という Perl 製品を構築した、別の成功したオープンソースビジネスです。Bricolage は、ETOnline (www.etonline.com) や World Health Organization (www.who.int) などを含む、比較的大きなウェブサイトで使われています。最近、Howard Dean campaign (www.deanforamerica.com) は、1 日に何百万にものぼるページの閲覧があり、ピーク時にはその何十倍もの要求があるサイトの頻繁な更新を処理するため、内容管理システムとして、Bricolage を採用しました。

これらと幾分関連するビジネスは、いつでも人気の高い MovableType (www.movabletype.org) のメーカーである SixApart (www.sixapart.com) です。SixApart は、MovableType を個人や非商用利用にはフリーライセンスで提供していますが、企業や商用の利用にはライセンスを課しています。間違えて欲しくないのですが、MovableType は、Perl で実装されていますが、プロプリエタリーなソフトウェアです。けれども、SixApart は、Perl ベースの製品を巡って利益の上がるビジネス構築を成し遂げたのです。

これらは、Perl で書いたソフトウェアを販売し、サポートするビジネスの初期段階にあります。これら 3 つの企業は、この道筋を拓いた唯一の企業というわけではありませんが、最も明らかな例であることは確かです。

結論

同僚が Perl に未来はあるかと尋ねた時、私は、今日の Perl の現状を見つめ始めました。彼が、"もちろん、Perl には未来がある!" や "Perl の未来は、Perl 6 と Parrot にある!" という反射的な私の答えに挑戦してくれたことを感謝したいと思います。

今日、Perl の世界では、多くのアクティビティーが進行しています。その多くは、いとも簡単に見過ごされています。コアの開発は、堅実な歩みを続けています。CPAN のアクティビティーは、まったく健全です。Perl は、すばやいハックや大規模システム、Perl ベースの製品が必要な場合でも、問題を解決することのできる環境であり続けています。Perl 6 を 2004 年中に見られない場合であっても、Perl 5 を使って行なうことのできる仕事は数多くあります。Perl 5 は、今でも、その仕事の多くをこなすことができるのです。

それでは、この調査を開始するきっかけとなったオリジナルの問題に戻ることにしましょう。"Perl は、Java や .NET と競争できるか" という問題です。問題を解決する場面では、Perl は、少なくとも、今日の Java や .NET と同等の機能をもつツールです。他のすべての言語を除外して 1 つのプラットフォームが伝道されるようになると、その時にはおそらく、Perl は、.NET や Java に太刀打ちできないでしょう。その場合でも、福音伝道が、座ってコードを書くことに関わる問題を、これまでに、いつ解決してくれたことがあるというのでしょうか。

もちろん、Java や .NET があなたにスピードを与えてくれるのであれば、これらの環境を使うべきであることは言うまでもありません。Perl の成功を、他の何らかの言語の失敗に基づいて述べることはできません。Perl の成功は、あなたの仕事を終わらせるのを助けてくれるかどうかにかかっているのです。

Perl.com へ行く。

Perl.com Compilation Copyright © 1998-2003 O'Reilly & Associates, Inc.