perlfaq1 - Perl に関する一般的な質問
このセクションでは、Perl に関する非常に一般的で高レベルの質問に答えます。
Perl は Larry Wall と数多い協力者によって書かれた、折衷的な遺産を持った 高水準プログラミング言語です。 それは遍在するプログラミング言語である C から派生し、 そしてそれ程ではないけれども、 sed、awk、Unix のシェルおよび少なくともダース単位の他のツールや言語に 影響を受けています。 Perl のプロセス、ファイル及びテキスト操作機能は、 クィックプロトタイピング、システムユーティリティ、ソフトウェアツール、 システム管理タスク、データベースアクセス、グラフィカルプログラミング、 ネットワーキング、そして world wide web プログラミングを含んだタスクに 特に適したものになっています。 これらの強みは、システム管理者や CGI スクリプトの作者に特に人気を博すもとと なっていますが、数学者、遺伝学者、ジャーナリスト、そして管理者も また Perl を利用しているのです。たぶんあなたもそうなるでしょう。
pre-populist なインターネットの独特の文化と、Perl の作者である Larry Wall の強い信条が、perl のフリーでオープンな配布政策を生じさせました。 Perl はその利用者によってサポートされています。コア、Perl の標準 ライブラリ、オプションモジュール、そしてあなたが今読んでいる資料は 全てボランティアの手で書かれました。 詳細は perl ソース配布セットの README ファイルの最後にあるパーソナルノートを 参照して下さい。 Perl のマイルストーンリリースについては perlhist(5.005 で追加) を参照してください
特に、(Perl Porters として知られる)コア開発チームは、お金を出してでも 購入したいと思うレベルのものよりも、さらに良いソフトウェアを無料で 作り出すのだと誓っている、非常に利他的な人達の寄せ集め部隊です。 http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/ や http://archive.develooper.com/perl5-porters@perl.org/ またはニュースゲートウェイ nntp://nntp.perl.org/perl.perl5.porters または その web インターフェースである http://nntp.perl.org/group/perl.perl5.porters , または http://dev.perl.org/perl5/docs/p5p-faq.html の FAQ を 通して延び延びとなっている開発についてかぎまわることもできます。 あるいは、perl5-porters-subscribe@perl.org へ登録願いを出すことに よってメイリングリストに参加することもできます (タイトルなしの空メールでかまいません)。
GNU プロジェクトはその配布セットに Perl を含んでいますが、"GNU Perl" のようなものはありません。 Perl は Free Software Foundation による作成も保守もされてはいません。 Perl のライセンス条件は GNU ソフトウェアが 通常取っているよりもさらにオープンなものとなっています。
あなたが望むなら、Perl の商用サポートを受けることが出来ます。 けれども、大半の利用者にとっては、非公式のサポートは期待水準以上のものでしょう。 詳しくは "Where can I buy a commercial version of perl?" (どこで商用版 Perl を買うことが出来ますか?) の回答を参照してください。
(brian d foy によって寄贈されました)
これはしばしば見解と嗜好の問題であり、誰にでも適応する一つの答えというものは ありません。 一般的に、現在の安定版か、その一つ前の安定版を使いたいでしょう。 現在のところ、それぞれ perl5.14.x と perl5.12.x となります。
それはそれとして、いくつかの事柄を考慮して、どれがあなたにとって 最良であるかを決定する必要があります。
物事がおかしくなっていないなら、perl をアップグレードすることでおかしくなる (または少なくとも新しい警告が出る)可能性があります。
最新バージョンの perl はより多くのバグが修正されています。
Perl のコミュニティは最新リリースのサポートに集中するので、 それらに対する助けは早く得られます。
perl5.004 以前のバージョンにはバッファオーバーフローによる重大な セキュリティ問題があり、その一部には CERT アドバイザリ (例えば、 http://www.cert.org/advisories/CA-1997-17.html) があります。
最新版はあまり使われていなくて十分にテストされていないので、 もしリスクを嫌うならリリース後数ヶ月待って他の人がどんな問題を 抱えたかを確認したいかもしれません。
直前のリリース (つまり perl5.8.x ) は普通しばらくの間 メンテナンスされますが、カレントリリースと同じレベルではありません。
だれも積極的に Perl 4 をサポートしていません。 10 年前、(この文書によれば)ラクダの死体となりました。 今となっては白骨化しています。
Perl 6 のリリースの予定は決まっていませんが、準備ができた時点で 利用可能になります。 これはクリスマスに計画されていますが、どのクリスマスかはわかりません、という 冗談があります。 注目していてください; 但し、Perl のメジャーバージョンを 変更しなければならないのではないかという心配は不要です; 誰も Perl 5 をあなたから取り上げようとはしません。
実際の perl の開発は 2 つの路線があります: メンテナンス版と実験版です。 メンテナンス版は安定していて、マイナーリリース番号に偶数を使います (例えば、perl5.10.0; 10 がマイナーリリース番号です)。 実験版は安定版に含まれていない機能が含まれていて、マイナーリリース番号に 奇数を使います(例えば、perl5.9.x; 9 がマイナーリリース番号です)。
(brian d foy によって寄贈されました)
短く言うと、Perl 4 は過去、Perl 5 は現在、Perl 6 は未来です。
"Perl" の後ろの数字(例えば "Perl 5" の 5)は perl インタプリタの メジャーリリース番号であり、言語のバージョンでもあります。 メジャーバージョン毎に、以前のバージョンでは対応できない 大きな違いがあります。
現在の Perl のメジャーリリースは Perl 5 あり、1994 年に最初に リリースされました。 以前のメジャーリリースである Perl 4 (1991 年 3 月リリース) のスクリプトも 動きますが、重大な違いがあります。 リファレンスの概念、複雑なデータ構造、モジュールが導入されました。 Perl 5 インタプリタは以前の perl のソースから完全に書き直されました。
Perl 6 は Perl の次のメジャーバージョンですが、 although it's not intended to replace Perl 5. 文法と設計の両面において未だに開発中です。 作業は 2002 年に開始しましたが、未だに進行中です。 もっとも興味深い機能の一部は最新版の Perl 5 に現れていて、Perl 5 モジュールの中にはプログラム中にいくつかの Perl 6 の文法を使えるように するものもあります。 現在先導している Perl 6 の実装は Rakudo ( http://rakudo.org ) です。
Perl の改訂の歴史に関しては perlhist を参照してください。
(brian d foy によって寄贈されました)
Ponie は "Perl On the New Internal Engine" という意味で、 Fotango の Arthur Bergman が 2003 年に開始し、その後 Perl Foundation の プロジェクトとなりました。 これは 2006 年に放棄されました ( http://www.nntp.perl.org/group/perl.ponie.dev/487 )。
Ponie は、現在の Perl の内部を使わずに、Perl 5 から Perl 6 (あるいは 実際のところ Parrot が目標としていないなんでも) への変換パスを提供する ための新しいものを作ることを目標としていました。 Perl 6 バイトコードをコンパイルして実行する仮想マシンである Parrot で Perl 5 を使い続けられるでしょう。
第 2 回 O'Reilly Open Source Software Convention において、Larry Wall は Perl 6 の開発を本格的に開始するとアナウンスしました。 Perl 6 は Chip Salzenberg による Topaz と呼ばれる Perl を C++ で書き直す プロジェクトでしばしば使われていました。 Topaz は Perl の次のバージョンと その実装への価値ある知見をもたらしましたが、完全に中断しています。
Perl 6 についてもっと知りたい、または Perl をよりよき場所へと導く 十字軍を助けたいなら、Perl 6 開発者ページ http://dev.perl.org/perl6/ を 読んで、参加してください。
Perl 6 はまだリリースの予定はなく、Perl 5 は Perl 6 がリリースされた後も しばらくの間サポートされます。 何かをしようとする時に、Perl 6を待つ必要はありません。
"We're really serious about reinventing everything that needs reinventing." --Larry Wall
バグのフィックスと新機能を組み入れた本番リリースは、リリース前に 広くテストされます。 平均すると、5.000 のリリースからはだいたい一年に一回の割で 本番リリースをしてきました。
Larry と Perl 開発チームは時折言語内部のコアに対する変更を行いますが、 可能な限り旧版との互換性維持に努めています。 全ての Perl 4 スクリプトが Perl 5 の下で無傷で走るわけではありませんが、perl のアップデートによって、 (偶発的なバグフィックスの排除とまれな新しいキーワードがなければ) 以前のバージョンの perl 向けに書かれたプログラムを無効になってしまうことは ほとんどありえないでしょう。
いいえ。Perl は学び始めるのが容易で -- しかも学び続けるのが容易なのです。 Perl はあなたが(たぶん)慣れ親しんできたたいていのプログラミング 言語のように見えます。ですから、C プログラムを、awk スクリプトを、 シェルスクリプトを、はたまた BASIC のプログラムであろうと書いたことがあるのなら、 既に習得の途上にあるわけです。
たいていのタスクは Perl 言語の小さなサブセットを要求するだけです。 Perl の開発における指導的モットーのひとつは、「それを行うやり方は 一つではない」("there's more than one way to do it)というもので す(TMTOWTDI、時々"tim toady"と発音される)。 それ故、Perl の習得曲線は浅く (学びやすく)長い(もしほんとうに望むのならできることは山ほどある)のです。
最後に、Perl はしばしば(しかし常に、ではありません。定義によります) 言われるようにインタープリター型言語です。つまり、プログラムを書いたら、 中間コンパイルステップに入らずそのままテストでき、実験や、 テスト/デバッグをすばやく、かつ容易に行なえるようにしてくれるわけです。 この実験の容易さが、よりいっそう習得曲線を平らにします
Perl をより学びやすくするもの: UNIX の経験、ほとんどあらゆる種類の プログラミング経験、正規表現の理解、そして他の人のコードを理解する力。 あなたが何か行う必要がある場合、たぶんそれは行われており、 通常その仕事の事例はフリーで利用することができます。 Perl モジュールも忘れてはなりません。 それらは二章で議論されている CPAN と共に、 この FAQ の三章で議論されています。
いくつかの領域では優っていて、不利な部分もあるというところでしょう。 正確には、どの領域で有利でどの領域が不利かということは、個々人の好みの問題です。 ですから、この質問を Usenet で尋ねるのは非生産的な 聖戦を始めるという大きなリスクを伴います。
たぶん最も良い方法は、等価な仕事をするひとそろいのコードを書いてみることです。 これらの言語とも、それらについて(願わくば言い争うためでなく) 習うためのニュースグループを持っています。
どうしても、というのなら http://www.perl.com/doc/FMTEYEWTK/versus/ に 比較を行ったドキュメントが幾つかあります。
Perl は、オンラインのファイル処理タスクから複雑なシステムまでほとんど 全てのタスクで使うのに十分な柔軟性があり、高い拡張性を持っています。 多くの人々にとっては、Perl はシェルスクリプティングに対する 偉大な代用品として仕えます。 他の人々にとっては、C やC++ のような低水準言語でプログラムしてきた 大半のものに対する、便利で高水準な代用品として仕えます。 最終的には Perl をどのタスクに使ってどれに 使わないかはあなた(そしてたぶんあなたの管理)によります。
API を提供するライブラリがあれば、そこにあるコンポーネントをみんな、 ちょうどもうひとつの Perl 関数として、あるいは C や C++ で書かれ、 主要な perl インタープリタにダイナミックリンクされた Perl エクステンションを 使った変数として、利用することができます。 また、他の方向に行って、強力なアプリケーションを制作するために、 主要なプログラムを C や C++ で書いて、それをそのまま ちょっとした Perl コードにリンクさせることも可能です。 perlembed を参照してください。
ある種の問題に対しては単により便利で、特定の問題領域専用の、小型で、 集約された、特別な目的を持った言語は常にあるものだと言われています。 Perl はあらゆる人に対してあらゆるものであろうとしていますが、 誰かに対する何か特別なものではありません。 特化した言語の例としては prolog と matlab が思い浮かんできます。
あなたのマネージャがそれを禁じた時です -- しかし、マネージャー達を 交代させることを熟考して下さい :-)。
実際には、他の言語で記述されていてすでに使われているような(さらに それがうまく動いている)アプリケーションがあるとか、 ある特定のタスクのために特別にデザインされたアプリケーション言語(prolog や make など)があるというのが理由になるでしょう。
様々な理由により、Perl はリアルタイム組込みシステムとかデバイスドライバや コンテキスト切り替えなどの低レベルなオペレーティングシステムの開発作業、 複雑なマルチスレッド、共有メモリを使ったアプリケーション、 非常に大きなアプリケーションなどには向いていません。 あなたは perl が Perl それ自身で記述されてないということに 気がつくかも知れません。
Perl は基本的には動的に型付け(dynamically typed)される 言語であって、静的に型付け(statically typed)される言語ではないということを 理解してください。 原子力発電所で使うプログラムや脳外科手術モニタリングプログラムを 信用していないのであれば、懲らしめられることはありません。 そして、Larry もまた簡単に眠ってしまいます -- ウォール街は 抵抗するようプログラムされてはいません :-)
一ビット。 ああ、ASCII のことを話してるんじゃないの? :-) Larry は現在“Perl”をその言語の特性を表わすために使い、 “perl”を言語の実装、たとえばインタープリターとして使っています。 Tom の「お言葉」では「perl だけが Perl をパースできる」となります。
Before the first edition of Programming perl の初版が出る前、人々は普通この言語のことを "perl" と 呼び、これがインタプリタをさしていたのでその意味でタイトルになりました。 本の中で、Randal Schwartz は活字に組んだときに目立つように言語の名前を キャピタライズしました。 この慣例はコミュニティに受け入れられ、第二版では Programming Perl と いう形で、言語を意味するようにキャピタライズされた名前が使われています。
たとえば、"awk と perl" とか "Python と Perl" といった比較は良いように 見えますが、"awk と Perl" とか "Python と perl" はそうではありません。 ただし、"PERL" と書いてはいけません。 なぜなら、perl は何かの頭字語ではないからです。 実際のところは後づけのものがあるのですが。
Larry は気にしてはいません。 冗談交じりに彼がいうには、 「スクリプト(台本)はあなたを俳優にするもの。プログラムはあなたを 観衆にするもの」ということです。
元々は、スクリプトとはチャットスクリプトのように、 通常の対話コマンドの羅列でした。 uucp とか ppp のチャットスクリプト、あるいは .cshrc や .ircrc のような プログラムのスタートアップスクリプトがそうです。 チャットスクリプトは既にあるプログラムを 取り扱うためのドライバであり、独立したプログラムではありません。
コンピュータ科学者は全てのプログラムが解釈されることを正しく 説明しようとするでしょう。 しかしもしあなたがコンピュータ科学者ではない人にこの質問をしたならば、 彼らは プログラム は物理的なマシンコードに一度コンパイルされて 何度もそれを実行することができるのに対して、スクリプト は 使われる度毎に変換されるという回答をするかもしれません。
今では"script"や"scripting"というのは、 悪徳な目的のために無遠慮な、あるいは無知な商人に捕らえられてしまった用語です。 これらは "non serious" や "not real programming" と同様、 不思議でしばしば軽蔑的な意味を持ち始めています。 そのようなわけで、これらの単語を使わないようにしている Perl プログラマもいます。
(brian d foy によって寄贈されました)
JAPH は "Just another Perl hacker," を意味し、Randal Schwartz 1980 年代 後半から電子メールと USENET のメッセージへのサインとして使い始めました。 彼はは以前多くの話題にこのフレーズを使っていた("Just another x hacker,") ので、JAPH を区別するために、彼はこれらを Perl プログラムのように 書き始めました:
print "Just another Perl hacker,";他の人々がこれを取り上げて、同じ出力を生成する気の利いた、または わかりにくいプログラムを書き始め、事態は急速に制御不能となりましたが、 未だに作者と読者にとって楽しみの時間を提供しています。
CPAN には http://www.cpan.org/misc/japh に、 いくつかの JAPH プログラムがあります。
(brian d foy によって寄贈されました)
"larry wall quotes" でググりましょう! "I feel lucky" ボタンを使ってもいいかもしれません。:)
Wikiquote には、Larry による usenet への投稿やソースコードのコメントにある 名言があります。
プレーンテキストファイルがほしいなら、 http://www.cpan.org/misc/lwall-quotes.txt.gz を見てください。
(brian d foy によって寄贈されました)
彼ら自身の関心に訴えてください! もし彼らにとって Perl が新しい(従って恐ろしい) ものなら、 Perl が彼らの問題のひとつを解決できるようなことを何かひとつ 見つけてください。 これによって、Perl が何か(時間、悩み、時間)を節約するか、 何か(柔軟性、力、テスト可能性)を与えることを意味するかもしれません。
一般的に、ある言語の利点は、その言語を使う人々のスキルに大きな関係が あります。 もし Perl によってあなたはあなたのチームがより速く、より良く、より 強くなれるなら、あなたはより多くの価値を届けることができます。 人々はしばしば、そこから何を得られるかによりよく反応することを 覚えておいてください。 もし抵抗に遭った場合は、その人々が他の選択肢から何を引き出しているか、 そしてどうすれば Perl がその要求を満たすかを見つけ出してください。
Perl を探したり買ったりする心配する必要はありません; Perl はフリーで 利用でき、いくつかの有名なオペレーティングシステムは Perl を同梱しています。 Perlmonks ( http://www.perlmonks.com ) のようにあちこちにあるコミュニティ サポートと、様々な Perl メーリングリスト ( http://lists.perl.org ) によって、 たいていはあなたの問題に対する素早い回答を得られます。
最後に、Perl が全ての作業に対して正しいツールとは限らないことを心に 留めておいてください。 あなたの主張が妥当で、現実に基いたものであれば、あなたは遥かによい 提唱者となります。 なんであれ独善的な主張を行うと、人々はあなたの主張を割り引いて扱う 傾向があります。 全ての選択にはトレードオフがありますので、Perl という選択に対して あり得る弱点について素直になりましょう。
以下のリンクが有用かもしれません:
http://perltraining.com.au/whyperl.html
http://www.perl.org/advocacy/whyperl.html
Copyright (c) 1997-2010 Tom Christiansen, Nathan Torkington, and other authors as noted. All rights reserved.
This documentation is free; you can redistribute it and/or modify it under the same terms as Perl itself.
Irrespective of its distribution, all code examples here are in the public domain. You are permitted and encouraged to use this code and any derivatives thereof in your own programs for fun or for profit as you see fit. A simple comment in the code giving credit to the FAQ would be courteous but is not required.