5.14.1

名前

perlfaq1 - General Questions About Perl

perlfaq1 - Perl に関する一般的な質問

説明

This section of the FAQ answers very general, high-level questions about Perl.

このセクションでは、Perl に関する非常に一般的で高レベルの質問に答えます。

Perlってなんですか?

Perl is a high-level programming language with an eclectic heritage written by Larry Wall and a cast of thousands. It derives from the ubiquitous C programming language and to a lesser extent from sed, awk, the Unix shell, and at least a dozen other tools and languages. Perl's process, file, and text manipulation facilities make it particularly well-suited for tasks involving quick prototyping, system utilities, software tools, system management tasks, database access, graphical programming, networking, and world wide web programming. These strengths make it especially popular with system administrators and CGI script authors, but mathematicians, geneticists, journalists, and even managers also use Perl. Maybe you should, too.

Perl は Larry Wall と数多い協力者によって書かれた、折衷的な遺産を持った 高水準プログラミング言語です。 それは遍在するプログラミング言語である C から派生し、 そしてそれ程ではないけれども、 sed、awk、Unix のシェルおよび少なくともダース単位の他のツールや言語に 影響を受けています。 Perl のプロセス、ファイル及びテキスト操作機能は、 クィックプロトタイピング、システムユーティリティ、ソフトウェアツール、 システム管理タスク、データベースアクセス、グラフィカルプログラミング、 ネットワーキング、そして world wide web プログラミングを含んだタスクに 特に適したものになっています。 これらの強みは、システム管理者や CGI スクリプトの作者に特に人気を博すもとと なっていますが、数学者、遺伝学者、ジャーナリスト、そして管理者も また Perl を利用しているのです。たぶんあなたもそうなるでしょう。

だれが Perl をサポートしているのですか? 誰が開発しているのですか? なぜフリーなのでしょうか?

The original culture of the pre-populist Internet and the deeply-held beliefs of Perl's author, Larry Wall, gave rise to the free and open distribution policy of perl. Perl is supported by its users. The core, the standard Perl library, the optional modules, and the documentation you're reading now were all written by volunteers. See the personal note at the end of the README file in the perl source distribution for more details. See perlhist (new as of 5.005) for Perl's milestone releases.

pre-populist なインターネットの独特の文化と、Perl の作者である Larry Wall の強い信条が、perl のフリーでオープンな配布政策を生じさせました。 Perl はその利用者によってサポートされています。コア、Perl の標準 ライブラリ、オプションモジュール、そしてあなたが今読んでいる資料は 全てボランティアの手で書かれました。 詳細は perl ソース配布セットの README ファイルの最後にあるパーソナルノートを 参照して下さい。 Perl のマイルストーンリリースについては perlhist(5.005 で追加) を参照してください

In particular, the core development team (known as the Perl Porters) are a rag-tag band of highly altruistic individuals committed to producing better software for free than you could hope to purchase for money. You may snoop on pending developments via the archives at http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/ and http://archive.develooper.com/perl5-porters@perl.org/ or the news gateway nntp://nntp.perl.org/perl.perl5.porters or its web interface at http://nntp.perl.org/group/perl.perl5.porters , or read the faq at http://dev.perl.org/perl5/docs/p5p-faq.html , or you can subscribe to the mailing list by sending perl5-porters-subscribe@perl.org a subscription request (an empty message with no subject is fine).

特に、(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 へ登録願いを出すことに よってメイリングリストに参加することもできます (タイトルなしの空メールでかまいません)。

While the GNU project includes Perl in its distributions, there's no such thing as "GNU Perl". Perl is not produced nor maintained by the Free Software Foundation. Perl's licensing terms are also more open than GNU software's tend to be.

GNU プロジェクトはその配布セットに Perl を含んでいますが、"GNU Perl" のようなものはありません。 Perl は Free Software Foundation による作成も保守もされてはいません。 Perl のライセンス条件は GNU ソフトウェアが 通常取っているよりもさらにオープンなものとなっています。

You can get commercial support of Perl if you wish, although for most users the informal support will more than suffice. See the answer to "Where can I buy a commercial version of perl?" for more information.

あなたが望むなら、Perl の商用サポートを受けることが出来ます。 けれども、大半の利用者にとっては、非公式のサポートは期待水準以上のものでしょう。 詳しくは "Where can I buy a commercial version of perl?" (どこで商用版 Perl を買うことが出来ますか?) の回答を参照してください。

どのバージョンの Perl を使うべきなのでしょうか?

(contributed by brian d foy)

(brian d foy によって寄贈されました)

There is often a matter of opinion and taste, and there isn't any one answer that fits everyone. In general, you want to use either the current stable release, or the stable release immediately prior to that one. Currently, those are perl5.14.x and perl5.12.x, respectively.

これはしばしば見解と嗜好の問題であり、誰にでも適応する一つの答えというものは ありません。 一般的に、現在の安定版か、その一つ前の安定版を使いたいでしょう。 現在のところ、それぞれ perl5.14.x と perl5.12.x となります。

Beyond that, you have to consider several things and decide which is best for you.

それはそれとして、いくつかの事柄を考慮して、どれがあなたにとって 最良であるかを決定する必要があります。

  • If things aren't broken, upgrading perl may break them (or at least issue new warnings).

    物事がおかしくなっていないなら、perl をアップグレードすることでおかしくなる (または少なくとも新しい警告が出る)可能性があります。

  • The latest versions of perl have more bug fixes.

    最新バージョンの perl はより多くのバグが修正されています。

  • The Perl community is geared toward supporting the most recent releases, so you'll have an easier time finding help for those.

    Perl のコミュニティは最新リリースのサポートに集中するので、 それらに対する助けは早く得られます。

  • Versions prior to perl5.004 had serious security problems with buffer overflows, and in some cases have CERT advisories (for instance, http://www.cert.org/advisories/CA-1997-17.html ).

    perl5.004 以前のバージョンにはバッファオーバーフローによる重大な セキュリティ問題があり、その一部には CERT アドバイザリ (例えば、 http://www.cert.org/advisories/CA-1997-17.html) があります。

  • The latest versions are probably the least deployed and widely tested, so you may want to wait a few months after their release and see what problems others have if you are risk averse.

    最新版はあまり使われていなくて十分にテストされていないので、 もしリスクを嫌うならリリース後数ヶ月待って他の人がどんな問題を 抱えたかを確認したいかもしれません。

  • The immediate, previous releases (i.e. perl5.8.x ) are usually maintained for a while, although not at the same level as the current releases.

    直前のリリース (つまり perl5.8.x ) は普通しばらくの間 メンテナンスされますが、カレントリリースと同じレベルではありません。

  • No one is actively supporting Perl 4. Ten years ago it was a dead camel carcass (according to this document). Now it's barely a skeleton as its whitewashed bones have fractured or eroded.

    だれも積極的に Perl 4 をサポートしていません。 10 年前、(この文書によれば)ラクダの死体となりました。 今となっては白骨化しています。

  • There is no Perl 6 release scheduled, but it will be available when it's ready. The joke is that it's scheduled for Christmas, but that we just don't know which one. Stay tuned, but don't worry that you'll have to change major versions of Perl; no one is going to take Perl 5 away from you.

    Perl 6 のリリースの予定は決まっていませんが、準備ができた時点で 利用可能になります。 これはクリスマスに計画されていますが、どのクリスマスかはわかりません、という 冗談があります。 注目していてください; 但し、Perl のメジャーバージョンを 変更しなければならないのではないかという心配は不要です; 誰も Perl 5 をあなたから取り上げようとはしません。

  • There are really two tracks of perl development: a maintenance version and an experimental version. The maintenance versions are stable, and have an even number as the minor release (i.e. perl5.10.x, where 10 is the minor release). The experimental versions may include features that don't make it into the stable versions, and have an odd number as the minor release (i.e. perl5.9.x, where 9 is the minor release).

    実際の perl の開発は 2 つの路線があります: メンテナンス版と実験版です。 メンテナンス版は安定していて、マイナーリリース番号に偶数を使います (例えば、perl5.10.0; 10 がマイナーリリース番号です)。 実験版は安定版に含まれていない機能が含まれていて、マイナーリリース番号に 奇数を使います(例えば、perl5.9.x; 9 がマイナーリリース番号です)。

Perl 4, Perl 5, Perl 6 って何ですか?

(contributed by brian d foy)

(brian d foy によって寄贈されました)

In short, Perl 4 is the past, Perl 5 is the present, and Perl 6 is the future.

短く言うと、Perl 4 は過去、Perl 5 は現在、Perl 6 は未来です。

The number after Perl (i.e. the 5 after Perl 5) is the major release of the perl interpreter as well as the version of the language. Each major version has significant differences that earlier versions cannot support.

"Perl" の後ろの数字(例えば "Perl 5" の 5)は perl インタプリタの メジャーリリース番号であり、言語のバージョンでもあります。 メジャーバージョン毎に、以前のバージョンでは対応できない 大きな違いがあります。

The current major release of Perl is Perl 5, and was first released in 1994. It can run scripts from the previous major release, Perl 4 (March 1991), but has significant differences. It introduced the concept of references, complex data structures, and modules. The Perl 5 interpreter was a complete re-write of the previous perl sources.

現在の Perl のメジャーリリースは Perl 5 あり、1994 年に最初に リリースされました。 以前のメジャーリリースである Perl 4 (1991 年 3 月リリース) のスクリプトも 動きますが、重大な違いがあります。 リファレンスの概念、複雑なデータ構造、モジュールが導入されました。 Perl 5 インタプリタは以前の perl のソースから完全に書き直されました。

Perl 6 is the next major version of Perl, although it's not intended to replace Perl 5. It's still in development in both its syntax and design. The work started in 2002 and is still ongoing. Some of the most interesting features have shown up in the latest versions of Perl 5, and some Perl 5 modules allow you to use some Perl 6 syntax in your programs. The current leading implementation of Perl 6 is Rakudo ( http://rakudo.org ).

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 ) です。

See perlhist for a history of Perl revisions.

Perl の改訂の歴史に関しては perlhist を参照してください。

Ponie って何ですか?

(contributed by brian d foy)

(brian d foy によって寄贈されました)

Ponie stands for "Perl On the New Internal Engine", started by Arthur Bergman from Fotango in 2003, and subsequently run as a project of The Perl Foundation. It was abandoned in 2006 ( http://www.nntp.perl.org/group/perl.ponie.dev/487 ).

Ponie は "Perl On the New Internal Engine" という意味で、 Fotango の Arthur Bergman が 2003 年に開始し、その後 Perl Foundation の プロジェクトとなりました。 これは 2006 年に放棄されました ( http://www.nntp.perl.org/group/perl.ponie.dev/487 )。

Instead of using the current Perl internals, Ponie aimed to create a new one that would provide a translation path from Perl 5 to Perl 6 (or anything else that targets Parrot, actually). You would have been able to just keep using Perl 5 with Parrot, the virtual machine which will compile and run Perl 6 bytecode.

Ponie は、現在の Perl の内部を使わずに、Perl 5 から Perl 6 (あるいは 実際のところ Parrot が目標としていないなんでも) への変換パスを提供する ための新しいものを作ることを目標としていました。 Perl 6 バイトコードをコンパイルして実行する仮想マシンである Parrot で Perl 5 を使い続けられるでしょう。

Perl 6 ってなんですか?

At The Second O'Reilly Open Source Software Convention, Larry Wall announced Perl 6 development would begin in earnest. Perl 6 was an oft used term for Chip Salzenberg's project to rewrite Perl in C++ named Topaz. However, Topaz provided valuable insights to the next version of Perl and its implementation, but was ultimately abandoned.

第 2 回 O'Reilly Open Source Software Convention において、Larry Wall は Perl 6 の開発を本格的に開始するとアナウンスしました。 Perl 6 は Chip Salzenberg による Topaz と呼ばれる Perl を C++ で書き直す プロジェクトでしばしば使われていました。 Topaz は Perl の次のバージョンと その実装への価値ある知見をもたらしましたが、完全に中断しています。

If you want to learn more about Perl 6, or have a desire to help in the crusade to make Perl a better place then read the Perl 6 developers page at http://dev.perl.org/perl6/ and get involved.

Perl 6 についてもっと知りたい、または Perl をよりよき場所へと導く 十字軍を助けたいなら、Perl 6 開発者ページ http://dev.perl.org/perl6/ を 読んで、参加してください。

Perl 6 is not scheduled for release yet, and Perl 5 will still be supported for quite awhile after its release. Do not wait for Perl 6 to do whatever you need to do.

Perl 6 はまだリリースの予定はなく、Perl 5 は Perl 6 がリリースされた後も しばらくの間サポートされます。 何かをしようとする時に、Perl 6を待つ必要はありません。

"We're really serious about reinventing everything that needs reinventing." --Larry Wall

"We're really serious about reinventing everything that needs reinventing." --Larry Wall

Perl はどのくらい安定しているのでしょうか?

Production releases, which incorporate bug fixes and new functionality, are widely tested before release. Since the 5.000 release, we have averaged only about one production release per year.

バグのフィックスと新機能を組み入れた本番リリースは、リリース前に 広くテストされます。 平均すると、5.000 のリリースからはだいたい一年に一回の割で 本番リリースをしてきました。

Larry and the Perl development team occasionally make changes to the internal core of the language, but all possible efforts are made toward backward compatibility. While not quite all Perl 4 scripts run flawlessly under Perl 5, an update to perl should nearly never invalidate a program written for an earlier version of perl (barring accidental bug fixes and the rare new keyword).

Larry と Perl 開発チームは時折言語内部のコアに対する変更を行いますが、 可能な限り旧版との互換性維持に努めています。 全ての Perl 4 スクリプトが Perl 5 の下で無傷で走るわけではありませんが、perl のアップデートによって、 (偶発的なバグフィックスの排除とまれな新しいキーワードがなければ) 以前のバージョンの perl 向けに書かれたプログラムを無効になってしまうことは ほとんどありえないでしょう。

Perl は学ぶのが難しいのでしょうか?

No, Perl is easy to start learning--and easy to keep learning. It looks like most programming languages you're likely to have experience with, so if you've ever written a C program, an awk script, a shell script, or even a BASIC program, you're already partway there.

いいえ。Perl は学び始めるのが容易で -- しかも学び続けるのが容易なのです。 Perl はあなたが(たぶん)慣れ親しんできたたいていのプログラミング 言語のように見えます。ですから、C プログラムを、awk スクリプトを、 シェルスクリプトを、はたまた BASIC のプログラムであろうと書いたことがあるのなら、 既に習得の途上にあるわけです。

Most tasks only require a small subset of the Perl language. One of the guiding mottos for Perl development is "there's more than one way to do it" (TMTOWTDI, sometimes pronounced "tim toady"). Perl's learning curve is therefore shallow (easy to learn) and long (there's a whole lot you can do if you really want).

たいていのタスクは Perl 言語の小さなサブセットを要求するだけです。 Perl の開発における指導的モットーのひとつは、「それを行うやり方は 一つではない」("there's more than one way to do it)というもので す(TMTOWTDI、時々"tim toady"と発音される)。 それ故、Perl の習得曲線は浅く (学びやすく)長い(もしほんとうに望むのならできることは山ほどある)のです。

Finally, because Perl is frequently (but not always, and certainly not by definition) an interpreted language, you can write your programs and test them without an intermediate compilation step, allowing you to experiment and test/debug quickly and easily. This ease of experimentation flattens the learning curve even more.

最後に、Perl はしばしば(しかし常に、ではありません。定義によります) 言われるようにインタープリター型言語です。つまり、プログラムを書いたら、 中間コンパイルステップに入らずそのままテストでき、実験や、 テスト/デバッグをすばやく、かつ容易に行なえるようにしてくれるわけです。 この実験の容易さが、よりいっそう習得曲線を平らにします

Things that make Perl easier to learn: Unix experience, almost any kind of programming experience, an understanding of regular expressions, and the ability to understand other people's code. If there's something you need to do, then it's probably already been done, and a working example is usually available for free. Don't forget Perl modules, either. They're discussed in Part 3 of this FAQ, along with CPAN, which is discussed in Part 2.

Perl をより学びやすくするもの: UNIX の経験、ほとんどあらゆる種類の プログラミング経験、正規表現の理解、そして他の人のコードを理解する力。 あなたが何か行う必要がある場合、たぶんそれは行われており、 通常その仕事の事例はフリーで利用することができます。 Perl モジュールも忘れてはなりません。 それらは二章で議論されている CPAN と共に、 この FAQ の三章で議論されています。

Java, Python, REXX, Scheme, Tcl といった他の言語と比べて Perl はどうなんでしょうか?

Favorably in some areas, unfavorably in others. Precisely which areas are good and bad is often a personal choice, so asking this question on Usenet runs a strong risk of starting an unproductive Holy War.

いくつかの領域では優っていて、不利な部分もあるというところでしょう。 正確には、どの領域で有利でどの領域が不利かということは、個々人の好みの問題です。 ですから、この質問を Usenet で尋ねるのは非生産的な 聖戦を始めるという大きなリスクを伴います。

Probably the best thing to do is try to write equivalent code to do a set of tasks. These languages have their own newsgroups in which you can learn about (but hopefully not argue about) them.

たぶん最も良い方法は、等価な仕事をするひとそろいのコードを書いてみることです。 これらの言語とも、それらについて(願わくば言い争うためでなく) 習うためのニュースグループを持っています。

Some comparison documents can be found at http://www.perl.com/doc/FMTEYEWTK/versus/ if you really can't stop yourself.

どうしても、というのなら http://www.perl.com/doc/FMTEYEWTK/versus/ に 比較を行ったドキュメントが幾つかあります。

Perlで○○を行えますか?

Perl is flexible and extensible enough for you to use on virtually any task, from one-line file-processing tasks to large, elaborate systems. For many people, Perl serves as a great replacement for shell scripting. For others, it serves as a convenient, high-level replacement for most of what they'd program in low-level languages like C or C++. It's ultimately up to you (and possibly your management) which tasks you'll use Perl for and which you won't.

Perl は、オンラインのファイル処理タスクから複雑なシステムまでほとんど 全てのタスクで使うのに十分な柔軟性があり、高い拡張性を持っています。 多くの人々にとっては、Perl はシェルスクリプティングに対する 偉大な代用品として仕えます。 他の人々にとっては、C やC++ のような低水準言語でプログラムしてきた 大半のものに対する、便利で高水準な代用品として仕えます。 最終的には Perl をどのタスクに使ってどれに 使わないかはあなた(そしてたぶんあなたの管理)によります。

If you have a library that provides an API, you can make any component of it available as just another Perl function or variable using a Perl extension written in C or C++ and dynamically linked into your main perl interpreter. You can also go the other direction, and write your main program in C or C++, and then link in some Perl code on the fly, to create a powerful application. See perlembed.

API を提供するライブラリがあれば、そこにあるコンポーネントをみんな、 ちょうどもうひとつの Perl 関数として、あるいは C や C++ で書かれ、 主要な perl インタープリタにダイナミックリンクされた Perl エクステンションを 使った変数として、利用することができます。 また、他の方向に行って、強力なアプリケーションを制作するために、 主要なプログラムを C や C++ で書いて、それをそのまま ちょっとした Perl コードにリンクさせることも可能です。 perlembed を参照してください。

That said, there will always be small, focused, special-purpose languages dedicated to a specific problem domain that are simply more convenient for certain kinds of problems. Perl tries to be all things to all people, but nothing special to anyone. Examples of specialized languages that come to mind include prolog and matlab.

ある種の問題に対しては単により便利で、特定の問題領域専用の、小型で、 集約された、特別な目的を持った言語は常にあるものだと言われています。 Perl はあらゆる人に対してあらゆるものであろうとしていますが、 誰かに対する何か特別なものではありません。 特化した言語の例としては prolog と matlab が思い浮かんできます。

Perl でプログラムするべきではないのはどういう場合ですか?

When your manager forbids it--but do consider replacing them :-).

あなたのマネージャがそれを禁じた時です -- しかし、マネージャー達を 交代させることを熟考して下さい :-)。

Actually, one good reason is when you already have an existing application written in another language that's all done (and done well), or you have an application language specifically designed for a certain task (e.g. prolog, make).

実際には、他の言語で記述されていてすでに使われているような(さらに それがうまく動いている)アプリケーションがあるとか、 ある特定のタスクのために特別にデザインされたアプリケーション言語(prolog や make など)があるというのが理由になるでしょう。

For various reasons, Perl is probably not well-suited for real-time embedded systems, low-level operating systems development work like device drivers or context-switching code, complex multi-threaded shared-memory applications, or extremely large applications. You'll notice that perl is not itself written in Perl.

様々な理由により、Perl はリアルタイム組込みシステムとかデバイスドライバや コンテキスト切り替えなどの低レベルなオペレーティングシステムの開発作業、 複雑なマルチスレッド、共有メモリを使ったアプリケーション、 非常に大きなアプリケーションなどには向いていません。 あなたは perl が Perl それ自身で記述されてないということに 気がつくかも知れません。

Perl remains fundamentally a dynamically typed language, not a statically typed one. You certainly won't be chastised if you don't trust nuclear-plant or brain-surgery monitoring code to it. And Larry will sleep easier, too--Wall Street programs not withstanding. :-)

Perl は基本的には動的に型付け(dynamically typed)される 言語であって、静的に型付け(statically typed)される言語ではないということを 理解してください。 原子力発電所で使うプログラムや脳外科手術モニタリングプログラムを 信用していないのであれば、懲らしめられることはありません。 そして、Larry もまた簡単に眠ってしまいます -- ウォール街は 抵抗するようプログラムされてはいません :-)

“perl”と“Perl”の違いはなんですか?

One bit. Oh, you weren't talking ASCII? :-) Larry now uses "Perl" to signify the language proper and "perl" the implementation of it, i.e. the current interpreter. Hence Tom's quip that "Nothing but perl can parse Perl."

一ビット。 ああ、ASCII のことを話してるんじゃないの? :-) Larry は現在“Perl”をその言語の特性を表わすために使い、 “perl”を言語の実装、たとえばインタープリターとして使っています。 Tom の「お言葉」では「perl だけが Perl をパースできる」となります。

Before the first edition of Programming perl, people commonly referred to the language as "perl", and its name appeared that way in the title because it referred to the interpreter. In the book, Randal Schwartz capitalised the language's name to make it stand out better when typeset. This convention was adopted by the community, and the second edition became Programming Perl, using the capitalized version of the name to refer to the language.

Before the first edition of Programming perl の初版が出る前、人々は普通この言語のことを "perl" と 呼び、これがインタプリタをさしていたのでその意味でタイトルになりました。 本の中で、Randal Schwartz は活字に組んだときに目立つように言語の名前を キャピタライズしました。 この慣例はコミュニティに受け入れられ、第二版では Programming Perl と いう形で、言語を意味するようにキャピタライズされた名前が使われています。

You may or may not choose to follow this usage. For example, parallelism means "awk and perl" and "Python and Perl" look good, while "awk and Perl" and "Python and perl" do not. But never write "PERL", because perl is not an acronym, apocryphal folklore and post-facto expansions notwithstanding.

たとえば、"awk と perl" とか "Python と Perl" といった比較は良いように 見えますが、"awk と Perl" とか "Python と perl" はそうではありません。 ただし、"PERL" と書いてはいけません。 なぜなら、perl は何かの頭字語ではないからです。 実際のところは後づけのものがあるのですが。

Perl プログラム、それとも Perl スクリプト?

Larry doesn't really care. He says (half in jest) that "a script is what you give the actors. A program is what you give the audience."

Larry は気にしてはいません。 冗談交じりに彼がいうには、 「スクリプト(台本)はあなたを俳優にするもの。プログラムはあなたを 観衆にするもの」ということです。

Originally, a script was a canned sequence of normally interactive commands--that is, a chat script. Something like a UUCP or PPP chat script or an expect script fits the bill nicely, as do configuration scripts run by a program at its start up, such .cshrc or .ircrc, for example. Chat scripts were just drivers for existing programs, not stand-alone programs in their own right.

元々は、スクリプトとはチャットスクリプトのように、 通常の対話コマンドの羅列でした。 uucp とか ppp のチャットスクリプト、あるいは .cshrc.ircrc のような プログラムのスタートアップスクリプトがそうです。 チャットスクリプトは既にあるプログラムを 取り扱うためのドライバであり、独立したプログラムではありません。

A computer scientist will correctly explain that all programs are interpreted and that the only question is at what level. But if you ask this question of someone who isn't a computer scientist, they might tell you that a program has been compiled to physical machine code once and can then be run multiple times, whereas a script must be translated by a program each time it's used.

コンピュータ科学者は全てのプログラムが解釈されることを正しく 説明しようとするでしょう。 しかしもしあなたがコンピュータ科学者ではない人にこの質問をしたならば、 彼らは プログラム は物理的なマシンコードに一度コンパイルされて 何度もそれを実行することができるのに対して、スクリプト は 使われる度毎に変換されるという回答をするかもしれません。

Now that "script" and "scripting" are terms that have been seized by unscrupulous or unknowing marketeers for their own nefarious purposes, they have begun to take on strange and often pejorative meanings, like "non serious" or "not real programming". Consequently, some Perl programmers prefer to avoid them altogether.

今では"script"や"scripting"というのは、 悪徳な目的のために無遠慮な、あるいは無知な商人に捕らえられてしまった用語です。 これらは "non serious" や "not real programming" と同様、 不思議でしばしば軽蔑的な意味を持ち始めています。 そのようなわけで、これらの単語を使わないようにしている Perl プログラマもいます。

JAPH ってなんですか?

(contributed by brian d foy)

(brian d foy によって寄贈されました)

JAPH stands for "Just another Perl hacker,", which Randal Schwartz used to sign email and usenet messages starting in the late 1980s. He previously used the phrase with many subjects ("Just another x hacker,"), so to distinguish his JAPH, he started to write them as Perl programs:

JAPH は "Just another Perl hacker," を意味し、Randal Schwartz 1980 年代 後半から電子メールと USENET のメッセージへのサインとして使い始めました。 彼はは以前多くの話題にこのフレーズを使っていた("Just another x hacker,") ので、JAPH を区別するために、彼はこれらを Perl プログラムのように 書き始めました:

        print "Just another Perl hacker,";

Other people picked up on this and started to write clever or obfuscated programs to produce the same output, spinning things quickly out of control while still providing hours of amusement for their creators and readers.

他の人々がこれを取り上げて、同じ出力を生成する気の利いた、または わかりにくいプログラムを書き始め、事態は急速に制御不能となりましたが、 未だに作者と読者にとって楽しみの時間を提供しています。

CPAN has several JAPH programs at http://www.cpan.org/misc/japh .

CPAN には http://www.cpan.org/misc/japh に、 いくつかの JAPH プログラムがあります。

Larry Wall の「お言葉」(witticisms) はどこで手に入れられますか?

(contributed by brian d foy)

(brian d foy によって寄贈されました)

Google "larry wall quotes"! You might even try the "I feel lucky" button. :)

"larry wall quotes" でググりましょう! "I feel lucky" ボタンを使ってもいいかもしれません。:)

Wikiquote has the witticisms from Larry along with their source, including his usenet postings and source code comments.

Wikiquote には、Larry による usenet への投稿やソースコードのコメントにある 名言があります。

If you want a plain text file, try http://www.cpan.org/misc/lwall-quotes.txt.gz .

プレーンテキストファイルがほしいなら、 http://www.cpan.org/misc/lwall-quotes.txt.gz を見てください。

他の人に、どうすれば Perl を使うように説得できるでしょうか?

(contributed by brian d foy)

(brian d foy によって寄贈されました)

Appeal to their self interest! If Perl is new (and thus scary) to them, find something that Perl can do to solve one of their problems. That might mean that Perl either saves them something (time, headaches, money) or gives them something (flexibility, power, testability).

彼ら自身の関心に訴えてください! もし彼らにとって Perl が新しい(従って恐ろしい) ものなら、 Perl が彼らの問題のひとつを解決できるようなことを何かひとつ 見つけてください。 これによって、Perl が何か(時間、悩み、時間)を節約するか、 何か(柔軟性、力、テスト可能性)を与えることを意味するかもしれません。

In general, the benefit of a language is closely related to the skill of the people using that language. If you or your team can be faster, better, and stronger through Perl, you'll deliver more value. Remember, people often respond better to what they get out of it. If you run into resistance, figure out what those people get out of the other choice and how Perl might satisfy that requirement.

一般的に、ある言語の利点は、その言語を使う人々のスキルに大きな関係が あります。 もし Perl によってあなたはあなたのチームがより速く、より良く、より 強くなれるなら、あなたはより多くの価値を届けることができます。 人々はしばしば、そこから何を得られるかによりよく反応することを 覚えておいてください。 もし抵抗に遭った場合は、その人々が他の選択肢から何を引き出しているか、 そしてどうすれば Perl がその要求を満たすかを見つけ出してください。

You don't have to worry about finding or paying for Perl; it's freely available and several popular operating systems come with Perl. Community support in places such as Perlmonks ( http://www.perlmonks.com ) and the various Perl mailing lists ( http://lists.perl.org ) means that you can usually get quick answers to your problems.

Perl を探したり買ったりする心配する必要はありません; Perl はフリーで 利用でき、いくつかの有名なオペレーティングシステムは Perl を同梱しています。 Perlmonks ( http://www.perlmonks.com ) のようにあちこちにあるコミュニティ サポートと、様々な Perl メーリングリスト ( http://lists.perl.org ) によって、 たいていはあなたの問題に対する素早い回答を得られます。

Finally, keep in mind that Perl might not be the right tool for every job. You're a much better advocate if your claims are reasonable and grounded in reality. Dogmatically advocating anything tends to make people discount your message. Be honest about possible disadvantages to your choice of Perl since any choice has trade-offs.

最後に、Perl が全ての作業に対して正しいツールとは限らないことを心に 留めておいてください。 あなたの主張が妥当で、現実に基いたものであれば、あなたは遥かによい 提唱者となります。 なんであれ独善的な主張を行うと、人々はあなたの主張を割り引いて扱う 傾向があります。 全ての選択にはトレードオフがありますので、Perl という選択に対して あり得る弱点について素直になりましょう。

You might find these links useful:

以下のリンクが有用かもしれません:

  • http://perltraining.com.au/whyperl.html

  • http://www.perl.org/advocacy/whyperl.html

AUTHOR AND COPYRIGHT

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.