パスワードを忘れた? アカウント作成
5182 story

本家インタビュー:Perl開発者ラリー・ウォール 36

ストーリー by GetSet
翻訳作業お疲れ様 部門より

yh曰く、"本家インタビューの翻訳シリーズの第4回目は、Perl開発者のラリー・ウォール氏にご登場いただきたいと思います。インタビューは、ちょうど半年前、本家に掲載されたもので、Perl 6にまで通底するその設計思想と哲学、そして、宗教の影響が語られています。

なお、この翻訳は多くの方々の共同作業で実現しました。別に記して感謝申し上げます。"(…)

1) 「スクリプト言語」あるいは「プログラミング言語」としてのPerl
Marx_Mrvelousによる

私はPerlを主にスクリプト言語として長いこと使っています。実にほとんど、文字列の抽出とレポート作成に使うのですね。しかしながら、最近のPerlの発達を見ると、Perlは、(「単なる」スクリプト言語としての互換性を維持しつつも)もっともっといろんなことができるようになりそうです。

現在、Perlがどんな風に使われているとお考えですか? 大部分のひとが、Perlをログのパーシングのような単純作業にしか使っていないことには満足なのですか? コンパイル言語に対抗して、Perlでもより高度なアプリケーションが構築されるのを見たくありませんか?

ラリー:

Perlをログ・ファイルのパーシングに使ってくれていて、大いに結構。Perlは今までも「地味な」言語だったし、この先もずっとそうありたい(と願っている)。僕が80歳になって、世界中の人たちが僕を崇めてくれて、かつてないルネッサンスのひとと思ってくれたとさえしても、それでも僕は妻に言われるままにゴミを出しにいくつもりだ。僕は日本語を学んでいるけれど、だからといって、英語を話すのを止めるわけじゃないのだ。

とはいえ、ひとが成長(背伸び)するように、Perlも成長(背伸び)しつづける。Perlは長年に渡って、新しい能力を習得してきた。Perlは間違いなく、何にしてもその能力の限界まで使用されている。このことへの解決策は、人びとにPerlを使わせるのを止めさせることではなくて、Perlのダイナミックレンジを増大させることだ。

大切なのは、Perlでは「すでに」より高度なアプリケーションが構築されているということ。ただ、かつてのようにプロセスが簡単でなくなっているという面もいくつかある。難しい問題なのだ。Perl 5でも厄介なことが十分出来ていたことを誇りに思っていた。ときどき、僕はこんなスローガンを唱える。「簡単なことは容易に、難しいことはやればできるように。」

しかし、どんなスローガンにせよ、疑う余地がある思い込みが感情の奥に隠れている。何が簡単で何が困難かは明らかだと思い込んでいるし、現在容易なことはこの先も容易にするべきだと思い込んでいる。困難なものを容易にすると必ず、容易なものが困難になってしまうと考えるのだ。しかし時には、何が容易で何が困難かが明らかでないこともある。時として、相応しくないものが容易だったりする。そして、また時には、容易なものを困難にしたりせずに、困難なものを容易にする方法があるものだ。

Perl 5の複雑な点には、解決に必要なものもあるし、ないのもある。必要な複雑さは捨象することはできないけれど、不必要なそれは取り除けるんじゃないかと思っている。それで、何をするのもより容易になる。おそらく、大部分のことが…。

すべてのことが一度に簡単になるなんて幻想に浸ってはいない。パーフェクトな言語なんてものはないのだ。もっと表現の豊かな言語を作っても、ある意味、自分の思うことを確実に表現する方法を学ぶのより困難になるだけだ。力の代償ってことだ。マンハッタンは、ビーズ一組を理解するより難しいものだ。

Perl 6は、何につけても、日本語を学ぶほどには難しくないとお約束します。:-)

2) Perlの初心者
KoopaTroopaによる

私はコンピュータ・サイエンス専攻の学生で、最近、他の言語と同時にPerlにも大変興味を持ちました。実際のところ、Perlを日常的に(いや、ときどきでさえ)使う必要などほとんどないのですけれど、Perlを学ぶこと自体が目的になっていて熱中しているのです。

では、質問です。こういう姿勢でPerlを学ぼうとするなら(一般的な知識としてちょっとぐらいは使うでしょうが)、今、Perlを学ぶことに時間を費す価値はありますか、それともPerl 6のメジャー・バージョンアップを待った方がいいですか?

ラリー:

Perl 5を学んでも「損害」を被ることはないでしょう。こう言うと反対する――そうでなくても不快になる人がいるということはもちろん承知しているけどね。

それは、あなたの好奇心の程度しだいだね。時間とともに言語の設計がどう進化するのかを知りたいがためだけにPerl 5とPerl 6の両方を学ぶひともいる。そういうのはかなりのオタクだね。あなたがそういったひとりでないなら、ラッキーだと思うといいよ。Perl 5は見かけとは違って、まったくひどい言語というわけではない。その良い部分はすべて、Perl 6でも残そうと思っている。でも、Perl 5からPerl 6へ移行しようとするひとは、特にその猥雑な部分が欲求不満のもとだからといって、その部分を簡単に忘れ去るべきではないのだ。あなたも、本格的にPerl 6を使う必要がある状況になったら、いずれにせよ、Perl 5のレガシー・コードを扱わざるを得なくなるだろう。いつも答えているように、それはこういうこと:

ギルドールはしばらく黙っていました。「その情報は、おもしろくないな。」やっとかれはそういいました。「ガンダルフが遅れるとはいい前知らせではないなあ。でも、よくいう言葉に、魔法使には、おせっかいをやくな、変幻自在で、よくおこる、って。行くか待つか、その選択はあなたのものだ。」

「これもよくいうことですが、」と、フロドは答えました。「エルフに意見を求めるな、よしとあしとを、ともにいう、ってね。」

「ほんとかな?」と、ギルドールは笑いました。「エルフは軽々しく忠告を与えることはめったにない。忠告は、賢者から賢者に与えても、危険な贈り物だから。すべてがまちがいに走ることもあってね。しかしあなたはどのような忠告がほしい?あなたはあなた自身のことがらを、わたしに打ち明けていないから、どうしてわたしが、あなた以上にうまく選択できようか?しかしたって忠告が求められるなら、友人としてそれを差し上げよう。もはや一刻の猶予もなく、お立ちなさい。そしてもしあなたの出立前までにガンダルフが現われない場合には、こういっておく――一人で行くな。信頼のおける、そして自ら進んで行く気のある友人を連れて行け。さあ、ありがたく思ってほしいな。わたしが喜んでこんなおせっかいをしたわけでないものね。
(※出典:J. R. R. トールキン著,瀬田貞二・田中明子訳『新版 指輪物語〈1〉旅の仲間 上1』評論社文庫,1992年,pp. 192-193)

3) 構造化プログラミングとPerl
slashnot007による

私はPerlが好きですが、それは、Perlが構造化プログラミング言語でないゆえです。私の仕事で必要となるのは、50%がパーシング用の言語で、25%がプログラムとデーモンのシーケンサで、あと25%がメジャーなオブジェクト指向の言語です。

PerlはPythonぎらいにさせますね。私は、Pythonを使ってみようと何度かトライしたことがありますが、いつもPerlに戻ってしまいます。それは、私の日常的な必要性がパーシングにあるので、言語の選択がそうなるし、Perlのスキルが錆つかないのです。Pythonが構造化プログラミングにはより良いとしたとしても、両方の言語に通じる必要はないので、高度な処理もPerlでやっています。

というわけで質問ですが、Perl 6は、make perlをPythonのような構造化言語になるのですか? より複雑により無秩序にとなるのを危惧して、Perlを発達させないというのはいい考えだと思いませんか? (Javaが、半分は非難されているこみ入っていて冗長なライブラリによって、クリーン・スレートから巨大な混沌へと進化を遂げたのを見るにつけても。)

ラリー:

ええっと、あなたの言う「構造化」ってどういう意味ですか? 25年前には、ブロックには入口がひとつしかないという意味で、すべての言語が「構造化」されていると考えられていた。(ブロックには、出口はひとつに限るべきと考えていたひともいた。決定木の機能には、入口がひとつでも出口が複数あるので、ありがたいことに、そういう人はすでに少数派だけどね。)

あなたは、明らかに違った意味で、「構造化」と言っているね。文法は構造だし、違う言語は違う文法を持つよね。とはいえ、それがあなたの意図しているものではないでしょう。

あなたの言う「構造化(structured)」は、小学校の先生が言うようなヤツだと思う。「自由な遊び時間」の対義語で「スケジュールに基づいた(structured)遊び時間」のように。Pythonのスローガンは「何かをするのに明らかなやり方はひとつしかない」だけれど、それは、コンピュータからすれば結構なことだが、人間からすればサイテーだ。「先生の指示の範囲で、好きなように遊んでね」って。

Javaは、Pythonにくらべたら、その意味で、ほとんど構造化されてなかった、と思う。それがJavaの成功の理由の一部だったけれど、かなりの犠牲を払うことになった。Javaの問題のひとつは、ライブラリのカーペットの下にある生来の複雑さを一掃したことだ。それで、カーペットを何度も交換しなければならなかったわけだ。

仰るとおり、Javaは「クリーン・スレート」で始まった。でもそもそも、スレートが小さすぎた。Javaの「スケジュールに基づいた遊び時間」は、言語自身というより文化規範によって構造に課されたのだ。

Perlは、その意味では「構造化」されたことはない。自分が思うように好きなだけ構造化できるという意味では構造化されていたけれど。問題のすべては、構造というのは外部から課せられたものではなくて自由選択なのだということ。学校で休み時間に友だちと遊ぶとき、フットボールにするのを選ぶのは、先生に言われたからじゃないよね。

一般に、プログラミングはフットボールをするようなものだ。他の人とプレイするには、たくさんのルールに合意する必要があるよね。Perl 5では、ルールに合意するのが至極簡単というわけじゃない。だから、Perl 6ではもっと簡単にしたいと思っている。一般に、プログラミングをするには訓練が必要なのだ。けれど、自分自身で門を叩いて、訓練してほしい。他人にやってもらうのではなくてね。Perl 6では、門が開きやすくなるだろう。

僕の哲学では、あなたの代わりに門を叩くことはしない。だって、あなたがどのくらいの速度で上達したいのか分からないから。(Perl 6は、デフォルトから、あなたのために少しだけ門を開いてくれる――モジュールなりクラスを書けば、それが自動的にデフォルトになる。それをメイン・プログラムに使うよりもより厳密なものへと。)だが、あなたのためにそうしたくないのは、あなたがどのくらいの速度で学びたいのかを知っているのはあなただからだ。僕は知らない。ギルドールが言うように、あなたはあなた自身のことがらを、わたしに打ち明けていないから、どうして忠告ができようか。あなたがどれだけ一生懸命パドルを漕ぐのか僕は知らないから、あなたがどれだけ大きな波をキャッチできるかなんて、僕は分からない。誰しも、小さい波から始めるべきなんだ。

同じような問題は、子供にリーディングを教えるときにも出てくる。「言語全体を!」と主張するものもいれば、「フォニックスを!」(※綴りと発音の関係の規則を教える科目)と叫ぶものもいる。考えてみてくれ、どちらも事を単純化しすぎている。フォニックスもいくらかは学ばねばならないだろうし、それをベースにしてもっといろいろ学ぶことになるだろう。そして、それをベースにしてもっともっと。そうしてゆくゆくは、言語全体を直観することになる。言語全体をと主張するひとたちは、「専門家の驕り」と呼ばれるところにはまっていく。あなたは、上級者がどうやるのかを見て、誰もがどうやったらいいかを考えるよね。生まれつきリーディングにたけたひともいる。そういう人たちは、自然と理解して上達してしまう。でも、そんなふうに教えても、子供たちの半分はフォニックスなど理解しないだろう。

プログラミングも同様だ。言語の開発者は、上級者がどうプログラミングするのかを見たがるし、誰でも最初からそうプログラムするよう学ぶべきだと考えがちだ。それは、初心者サーファーに40フィートの波にちゃんと乗れというようなものだね。できちゃうひともいるけれど、だいたいのひとは失敗する。

Perlは、今必要なプログラミングをちょっと勉強すれば、利用者が学ぶ準備ができていないようなテクニックなど使わずとも、すぐに使えるように設計されている。でも、利用者が準備できたときには、Perlも一緒にそこへ追いつこうとする。ゴルフ・カートのスピードメーターは何度も0に戻るもんだと、初心者にはただ言ったりはしない。

4) Perl 6には、何を*いれない*か?
TreyHarrisによる

リクエストがあった機能のうち、Perl 6には絶対いれたくないナンバー1とは何でしたでしょうか? また、その理由はなんでしょうか?

ラリー:

それは、あなたが何を機能と呼ぶか、また何をリクエストと呼ぶかによるなぁ。dev.perl.orgのRFC全部を見てみれば、そこでは応急処置の提案がされがちで、その機能リクエストというののほとんどが何らかのレベルでは本来のものじゃないことに気づくだろう。やはり、これらすべては、単なる「助けてぇ」という叫びだととるのが良いと思う。コンピュータ言語の場合、応急処置の75%は、その下に弾傷を隠しているものだから。

そう、例えば、複数行コメントのRFCを正式には却下したけれど、実のところその一方で、ブロック状のコメントは難しすぎて書けないという前提は採用している。しかし、よりよい解決策は、文法をふやすことではなく、POD文法を皆が望むものにすることだ。

けれど、話はPerlだ。結局、解決策はひとつだけじゃいけない。もうひとつの解は、とにかくユーザが彼ら自身の複数行コメントの書き方を実装できるよう、Perl文法を十分融通の利くものにしてしまうことだ。さぁ、どうだ! 構文のゆがみがレキシカル・スコープで限定されるなら、僕はそれで申し分ない。「前もって宣言しておけばすべてよし。」

もうひとつ頻繁にリクエストされる機能でPerl 6に入らないものに、暗黙のレキシカル宣言がある。これは、コードの小さな断片を見ている分には良いアイディアに思える機能のひとつだ。しかし、ひと目で見られる以上にスコープが広くなっていくと、破綻を来す。インデントによるスコープ分けにも同様の問題があるのだが、どういうわけか、Perl 6には誰も真面目にはリクエストしてきていない…。

こう来ると$や@や%の記号を取り除くことが、機能リクエストのナンバー1だと思うかもしれない。でも、そんなのは、典型的に、Perlを知らない人とか、それらを取り除いたとしてもおそらくPerlを使わないであろう人しか提案しないものだ。Perlを知っている人は、そういった記号を好む傾向にある。

5) Perl vs 他言語
larry baginaによる

SlashdotでPerlの話題が出るといつも、Perlは古い、そんなのはやめてPHPとかRubyとかPythonを使うべきだ、と主張する狂信者たちが山のように現れます。

他のスクリプト言語についてはどうお考えですか? 好きなのとか嫌いなのはありますか?

ラリー:

まぁ、だいたい、僕が他のコンピュータ言語を好きじゃないのは、それがPerlじゃないからなんだけどね。:-)

冗談はさておき、Perlは、僕の考え方にかなりよくマッチしている。コンピュータ言語で僕が最も欲しいと思うのは、幅広いダイナミック・レンジだから。汚くって低級な要素とオシャレで高級な要素の両方を兼ね備えている言語を僕は求めている。赤ちゃん語でもオトナの喋りでも受け容れるような言語が欲しい。他の言語では、そういったレベルの違いがひとつに均されてしまう傾向にある。

詳しく言うと、Perl 6に暗黙のレキシカル・スコープを採り入れないことにした主な理由は、Rubyの例があったからだと言っておかねばならない。僕たちは、明示的なmy宣言にこの先もこだわっていたい。もっとも、僕はRubyの大部分は好きにならないといけないのだ。なぜかというと、それは単に、Rubyの大部分は、Perlから借りてきたものだからなんだけど。:-)

それから、Rubyの単項間接演算子*も好きだ。だから、Perl 6には借りてきた。

Rubyで僕が一番問題だと思うのは、暗黙のレキシカル・スコープがそうであるように、「驚き最小の原則」が人を迷わせるということだ。問題は、ひとは誰の驚きで悲観するのか、ということ。上級者は初心者とは違うことに驚くし、小さなプログラムを大きく育てようとする人は、最初から大きなプログラムを設計する人とは違うことに驚くのだ。

たとえば、なんでもオブジェクト扱いするのは、「初心者にとっての驚き最小の原則」の侵害だと思う。初心者にとっては、数字は数字だし、文字列は文字列だ。コンピュータが扱う限りでは、それらは当然オブジェクトなのだろうし、もちろん、上級者は、これらをオブジェクト扱いするのを問題にさえしない。けれど、いきなりオブジェクト指向を強いると、加速中の初心者にとっては徐行帯になってしまう。

白状すると、僕は、PHPみたいな正反対の言語が大好きだ。僕が書いた最初の実用的なコンパイラは、テキスト処理のマクロ言語の一種で、コマンドがデータに埋め込まれているものだった。見えない外側のループが想定されているawkのパターン、アクション文法などのように、処理の特定のフォームがデフォルトで想定されたプログラミング言語の、より一般的な部類だ。

Perlなら出来る。デフォルトではないけれど。awkやPHPのような言語は、特定の生態圏に帰属することで、結局は自分で自分に足枷をすることになる。特に、Perlのようななんでも屋がそういった生態圏を効果的に占領してしまうと。だから、僕はPHPをやってみようなんて誘惑に駆られたことなどない。PHPは名前空間や拡張機能に問題があるなんてことを言い出したら、受け売りになってしまう。だからそんなこと言わない。:-)

Pythonは、小さいコードを見渡すにはクールだ。けれど、「アウトライン」文法は大きなコードの塊を作ると失敗すると思う。アリストテレスの構成論によれば、話には序破急の三段階がある。だから、ブロックでなければいけないのだ。

誰でも同じスタイルでコードを書くよう強いるのがいいと言われているけれど、それはPerl流じゃない。少なくとも、「デフォルトの」Perl流じゃない。でも、前もって宣言しておけばすべてよし。ある種のスタイル・ポリシーを強いるモジュールを導入するのは大いに結構。あなたの会社がそういったものを導入して強いるのももちろん良い。もちろん、もし、「本物の」プログラミング作法を身につけたいなら、DamianのKlingonモジュールを使うのをお勧めしたい。

6) Perlと.NET
prostoalexによる

.NET一般とその枠組の中でのPerlの役割についての見解は何ですか? .NETがPerlを対応言語のひとつとしてサポートしたとすると、何らかのプロジェクトにそれを使うべきと実際に推奨しますか? この相乗りに明るい未来を感じますか?

ラリー:

僕の考えでは、.NETは、Perlをネイティブで動作するようにportすべきもうひとつのアーキテクチャに過ぎない。.NETとの互換性に必要なアプローチは今のところちょっとしたハック程度のものだと思う。十分に強力な型宣言の仕組みがないのはPerl側の問題だけど、動的に型を決定する言語を十分にサポートできていない.NET側にも問題がある。.NETやJavaマシンのような他のVMに載せるレイヤーないし(できれば薄い)接着剤の機能をするParrotインターフェイスのような何かを作ることになるんじゃないかな。それらのインピーダンスの違いが少ないほど、レイヤーも薄くできる。

Perlは、Perlを使う意味があるところで使うことをお勧めしたい。意味のないところには使わないでおこうよ。.NET上でPerlを使うことに意味があるかどうかを判断するのは僕ではできない。だって、僕はあまりにも無知で間抜けで、あなたのためにそういった判断はできない人だから。ごめんよ。

未来については、僕には本当に分からないんだ。はるか遠い昔(銀河の彼方)、僕はPerlとJavaをひとつのプロセスに詰め込んだことがあったけど、大して衆目を引かなかった。もちろんJava使いたちは100%Javaでないソリューションからは顔を背けたし、もう一方の側からも極めて冷たい反応しか返ってこなかった。概して、PerlプログラマたちはJavaにそれほど関心がないみたいだ。たぶん、浮世離れした言語設計者たちのほうが、普通の人たちよりもマルチランゲージでのソリューションが好きなんだろう。

もちろん、だからこそ、僕たちはParrotでまったく同じことをやろうとしているわけだね。やってやろうじゃないか。:-)

6.5) プロジェクト管理者の視点から
mustangdavisによる

Perlは2人以上のプログラマが必要なプロジェクト向けには設計されていないという人たちの意見についてはどう思われますか? 多くの人が、Perlのコードは1人でしか管理できないと何度も何度も主張しています…。そんな意見についてのお考えは? あなたは、どうやって大規模なPerlプロジェクトを管理しているのですか? Perlは大規模なプロジェクトに利用されるべきものだと思われますか? (または、Perlは間に合わせのプログラミング言語としてのみ利用されるべきでしょうか?) 余談ですが、私はあなたの業績を尊敬しています(誰かがこれを言うべきなんです)。

ラリー:

僕は大規模プロジェクトは「まったく」管理していないよ、見かけはその反対だけどね。管理職ってのはどうも向いてないもので。管理者としての裁量はみんな他の人に譲っているよ。誰でもいいから任された人に聞いてごらん…。

でも、Perlのコードが1人でしか管理できないと言う連中はみんな、絶対クラックよりひどいヤクでラリってるね。連中はそれをやってのけたたくさんの人たちのことをただ見落としている。でも、そこら辺の人を適当に雇ってきて一緒に小説を書こうなんて考えたりしないよね。一緒に仕事するのを理解する方法を既に分かっているとか、あるいは少なくとも生産的にお互い競い合う方法を知っているいい小説家を何人か雇ってなら、できる。そのレベルぐらいの専門性がない場合は、それに従って誰でも作業できるようなポリシーを掲げたり、ライアヴェックの世界みたいなライティングのルール、例えばどのストーリーにもラクダが出てくるようなルールを掲げたりすれば、できる。

言い換えれば、Perl 6を、大規模プロジェクトでも、管理者や設計者がプログラミングのポリシーといったものを決めるようにさせるという点で、Perl 6をよりよいものにするためにできることはあるっていうことだ。標準化されたOpaqueオブジェクトタイプを持つことも同じように役に立つだろう。Perl 6のオブジェクト指向が「ボルトで留めただけ」なんて誰も言い出しはしない。ううん、たぶんSlashdotにいる、理性的な議論と囃子立ての違いが分からないようなある種の連中を除けばね…。

7) 宗教の役割
Anonymous Cowdogによる

あなたがクリスチャンで、若い頃の伝道の衝動(善くあろう、他を助けたいという欲求)が、Perlに何年も注いでいる情熱の一部かもしないと書かれたものを読んだことがあります。

科学的な視点を好む私は、信仰深くもなく、そうありたいとも思いません。たぶん、神はいるでしょう。もしいるとしても、神は親指を持たない。すなわち言い替えれば、その神には何も変える力はなく、現実は(何であれ)ただ物理法則に従って働くだと思います。

いったいいかにすれば科学者、または少なくとも技術者としての心が神を信じることができるのか、信仰はPerlに関するあなたの業績にどのような役割を果たしているかを教えてください。

ラリー:

えっと、それはエッセイまるごとか、本1冊か、人生そのものが必要な話題だね。しかし、短くなるよう努力しよう。

あなたが「いったいいかにすれば」と言うのは、つまり、科学者の(または少なくとも技術者の!)心を持つものが神を信じることを選ぶなんてことは多かれ少なかれ想像できないことだと、あなたが考えているからだと思う。あなたには、それを少なくとも想像できるようになってほしい。この問題の大部分は、あなたが心から信じまいとしている神が、僕が心から信じる神とは違うことなのだろうと思う。神学論争というのは、何より議論がぶつかるだけのもので、理解されることは決してないのだ。

では、僕の意味するところを、明確に、また可能な限り少ない情報ビットに集約してみたい。既得権を持った多くの人たちが、話を不必要に分かりづらく困難にしている。しかし、これは子どもでも十分理解できるほど単純な「はずの」ことだ。自分を信仰心で満たす努力する必要などない――結局のところ、イエスは、からし種一粒ほどの信仰があればよいと言っている。では、それは情報理論的にはどれだけの大きさなのだろうか? それは、たったの2ビットだと思う。『ヘブル書』から、表現を少し変えて、2ビット程引用させてほしい。

エノクがしたように神を喜ばせるにはある程度の信仰が必要だ。なぜなら、神の御前に来る者は(少なくとも)次を信じなければならない。
 A) 神が存在し、
 B) 神を希求するものには、神は真に善きものとなる。
たったこれだけ。「善き知らせ」は子どもにも理解できる程に単純だが、哲学者には理解できない程に深い。

さて、あなたはビットAの可能性が1であることは喜んでお認めのようだ。つまり、もう半分近くまで来ていることになる。シュレディンガーの猫のようにいまだにあたりふらついている量子ビットならば、平均してまだ4分の1程の道のりかもしれないが。そこにいる観察者はあなたであって、僕ではない。――もちろんあなたが死んでいなければね。:-)

多くの人がBの地点で、さまざまな理由で立ち止まっている。ある人は論理的に、ある人は倫理的に、でもほとんどはやはりシュレディンガーだ。人びとは、Bの量子ビットを観察するのが恐ろしいのだろう。なぜなら、波動関数が0なり1に収束してほしくはないからだ。彼らには、どちらの選択も受け容れがたいと思われるから。不可知論を主張する多くの人は位置決めをしようとしない。それは、彼らが「分かってない」からではなくて、「分かりたがってない」からだ。時には何が何でもという程に分かりたがらない。

もしそれが0であることが分かった場合、人びとは本当に利己的な遺伝子の奴隷となり、さまざまな形態の同族意識以外に、倫理的なバイアスはなくなる。

そして、それが1であることが分かったら、それにともなうごまかしの全部を鵜呑みにすることになる。さぁ、どうだ?

僕はここまで逆向きに話してきたことを認める。僕は、信仰深い文化の中で育ったし、自分の信条をこれら2ビットに集約すべく、おそろしく多くのものを鵜呑みにはしないようにしなければならなかった。

そして、さらに集約することを試みたが、できなかった。なぜなら、神はこう言われたからだ。「それはやりすぎだ。私はすでに汝の信仰ビットに1を立てた。私は汝より上位の観察者だからだ。逆に汝がシュレディンガーの猫だ――汝は霊的には死んでいたが。が、私は汝の量子ビットを吟味し、そのどちらも1だと思う。それに反対する汝は何者ぞ?」

では、神に反対する私は何者なんだろう?:-) 神が真に宇宙の創造者であれば、すべての量子ビットを観察でき、さらに時にはよりよい物語をつくるために、いくつかのビットを反転しさえするだろう。それが創造者というものだ。創造者は親指を持つのか否か…。

一度、宇宙をこの観点から眺めると、多くの議論は重要ではなくなる。例えば、宇宙は原初に爆発して存在するようになったのだから、したがって、創造者なぞ存在しないのだというホーキング議論なども。しかし、それを言うなら、指輪物語が爆発して存在するようになったのも真理になるが、それは創造者がいないことを示しているわけではない。それは、創造者は被造物と同じスケジュールでは創造しないというだけの話だ。

もし神が創造者と同じく宇宙を斜めに創造したなら、その効果を見つめるに適当な場所は、あいまいな端ではなくて、その中心だろう。そして、僕自身は、イエスはその中心に立つと確信している。あなたが注意深く見つめ、そして、いかようにも導けるような色々なアジェンダを主張する様々な人たちに惑わされることなく、そして、自分で神を求めずにひとつの公式を追い求める罠に落ちることがなければ、その証拠があることに気づく。すべて人間集団は過ちをおかしがちだ。そして、あなたがその集団に所属することができるか否かを判断できるような公式を創り出す。しばしば、この公式は主義とか伝統とか呼ばれる。そして、他の人間文化にも何らかの価値があるのと同様に、それらにも何らかの価値はある。でもしかし、これはまったく的を射ていない。

「組織神学」というのは矛盾した言葉だ。神は体系ではない。クリスチャンは、次のように自問することを好む。「イエスならこんな場合どうするだろうか?」 不運にも、めったなことでは正解に行き当たることはない。その答えは「思いもしない何かだ!」 真に造物主が自身の物語を綴るなら、期待すべきはそれだ。創造的な答えだ。

そして、この創造性は移っていくようになっている。僕たちは、創造的であることを期待されている。そして、他のひとが創造的になるように力を貸すことを期待されている。

さて、これで、質問の最後の部分に(ようやく)戻ってきた。この話すべてが、どのようにPerlと関連するかだ。

Perlは、明らかに、他のひとが創造的になるように力を貸すための僕の試みだ。およばずながら、僕は、神が好む人たちを人びとがもう少し理解してくれるようにと、こっそり力を使っている。

さらに言うと、僕たちは、物語は、端ではなく中心で語られるべきだという考え方をもっている。これは、公式よりはむしろ見本で定義するべきだという、僕の言語に関する考え方に結び付いている。これは、誰が「善き」Perlプログラマかそうでないかとか、または誰がまさに「Perlコミュニティ」の一員であり誰がそうでないかを、定義することを私が拒んだこととも関連している。それらはすべて、中心で定義することであって、周縁で定義することではないのだ。

「何をするにもやり方は一つだけじゃない」(TMTOWTDI; There's more than one way to do it.)の哲学は、宇宙の創造者の謙虚さを観察した直接の結果であり、荘厳ではなく軽妙に処理できるよう選択した結果だ。宇宙には、押し付けるべきスタイルのガイドラインなどないのだ。創造力のある人たちは、それぞれ自分のスタイルで開発をする。そういう人たちによって、天国は善い場所になるのだ。

つまり、次の確信が基礎にあるのだ。科学と信仰をそれぞれの真ん中から定義したら、それらがぶつかり合うことはない。だから、Perl文化の持つ「信仰性」に関わらず、僕たちはコンピュータ・サイエンスの恩恵を信じることができる。僕がPerl 5に、レキシカルやクロージャを入れなかったのは、そんなことしたら、みんなが「ハレルヤ」と叫んで上に下にと跳ねまわるんじゃないかと心配したからだ。(結局はそうなったけど、それは僕のせいじゃない)

それではみなさんで、賛美歌42番を斉唱しましょう…。

8) ありがとう、ラリー
wdr1による

みなさんと同じように、私もPerlが大好きです。仕事でも個人的にも使っています。あなたは、私のキャリア形成を助けてくれるだけでなく、とても楽しい余暇の過ごし方を与えてくれたのです。お礼をするにはどうすればいいでしょう? お金は受け取ってもらえるのかしら? 誰かに何かものを寄付するとかは?

『プログラミングPerl』の新版が出版されたら、もう欲しいものなんてありません。(万歳、Perldoc!) Perlを偉大にしてくれたひとのポケットに、いくばくかのお金を差し上げたい。お礼をするにはこの他にどんな方法がありますか?

ラリー:

あぁ、なんというタイミングでしょう! あなたは、説教のあとにすぐ献金皿を差し出してくるような教会からいらしたのですね…。:-)

ありがとうと言ってくれるだけでも、とてもうれしい。でも、もっと力をくれるというなら、時間やお金を寄付する場所はいっぱいある。不運なことに、どうやって時間を寄付するか調べ出すには時間がかかる。あなたがどれかの団体に、つまりその、関心を持つまでには、いくつもの団体と付き合ってみないといけないしね。でも、Perl文化への貢献を尊重することもPerl文化の一部だから、あなたの貢献が技術的なものでないからといって後込みしないでください。僕たちはそんな風に活動しているわけじゃないから。

お金を寄付をするのは簡単(もちろんお金をどう使うかが難しいのだけれど)。(※アメリカの納税者なら)Perl Foundationへの寄付は、税控除が受けられる。今年の僕の支援の大部分は、Perl Foundationを通じてきている。これなしでは、僕はフルタイムでApocalypseを書くのは不可能だったろう。あなたが、自分の勤務する会社に、任意の額の寄付や、あなたの寄付金額と同じだけの寄付をしてもらうよう説得することができるようなら、それは、時間の投資に値する。(時には、苦痛となるけれどね。)この場をお借りして、いままで貢献をしてくださったみなさんに心から謝意を表します。この番組は、みなさんのような視聴者のおかげでお送りしています。

9) perl 6の生態圏
maraistによる

Perl 1~5は、UNIXの設定・管理用の言語として偉大なものでした。これには小規模なウェブ・サーバのプラットフォームも含まれますが、この生態圏を支配するという点でこれだけ汎用的な言語を、他に見つけるのは非常に困難です。共通のLook and Feelを用いると特に、スピードとパワーと簡素さとハフマン・コーディングの完璧なコンビネーションがありますね。

一方、perl 6においてはこの公式が変わっているように思います。より一般的なソリューションを重視して、(抽象化により)パフォーマンスを落しているように見えます。と同時に、UNIX系の文法から実質的に逸脱しているようにも思えます。特に、C類似の文法(:, ?, select, 例外処理など)や、awk,sed類似の正規表現や、Cライブラリのラッパーなど。Perlの習得や採用を極めて容易にしているのは、まさにこういった類似によるものです。企業の情報システム担当やUNIX管理者は、2日もあれば十分ものにできてしまいます。

さて、私の質問ですが、Perl 6はなんらかの生態圏を持つように計画していますか? もしくは、薄すぎるほどに広がっていく、つまり、より激しくJava、Python、C#と競争して自分の生態圏を失っていくと思いますか?

ラリー:

すごい質問だ。進化生物学者みたいに、生物が目的をもって進化しているかのように話すのが、僕は大好きだ。「よし。これからは羽を生やして鳥になるんだ…」ってヤツだ。で、Perlの場合ももちろんある程度(それじゃ不十分と言う人もいるだろうけど)目的は頭の中にある。他のPerl開発者の頭は数えない(それは多すぎってか? でも、よけて通れないだろう?)としても。でも、Perlが、まるでそれ自体が獣性を持つようにとか、あるいは、まるでこの文のように筆者の意図したプロットをはずれて暴走する小説の登場人物のように話すのはとても面白い。

いずれにしても、Perlはそもそも最初からいかなる特定の生態圏にも安住してきたことはない。それは、進化学的にはおそろしく健全なアプローチではない。特に、生態圏が消滅しようとしている場合にはね。Perlがこれまで安定した生態圏に上陸していたのはかなり幸運だったけれど、いつしかその生態圏の一部が干上がったとしても、それは結果的には予想できていたはずのことで、実際望ましいとすら言える。木にぶらさがっている人など誰ももういないのは、結局、生態圏がなくなるという災難があったからだろう。(もちろん、まだぶらさがっている人もいるかな。でも、そういった人たちはSlashdotを代表するわけじゃない。ええっと…、反対に見えるかもしれないけどね)

Perlは、――awkやsedよりもよい――テキスト処理言語として始まったけれど、その生態圏をシステム管理にまですぐに広げた。少なくともUNIXでは、多くのシステム管理はテキスト処理だ。しかし、バージョン3でperlは、バイナリ・データの処理機能を加えることで、極めて意図的にテキスト処理だけの生態圏から抜け出した。Perl 4では、期せずしてシステム管理からCGIやウェブの生態圏に広がった。Perl 5ではこの傾向を加速して、意図的に拡張グルー言語としての生態圏を占めた。それは(僕には)予測がつかなかったが、ウェブ・サイトが、すべてのバックエンドのデータベースをさまざまなテキストからなるインターネット・プロトコルに接続するように作られたことからは、予期できた結果だったと言える。

しかし、もしPerlが「なんでもできる」という生態圏に棲息するのをあなたが心配するなら、それは実にPerl 5からの意図だとお伝えしたい。結局、どんな言語でも完璧にせずにはオブジェクト指向を採り入れられないからね。;-)

真面目な話、今日Perlを使う人たちの多くは、すでにPerlの生態圏として「なんでも」というラベルを貼っている。みんながとはまだ言わないけれど。それらの人たちには、つまりPerlを「なんでも」の生態圏により良いものとしようとする試みは、実に論点にならない――すでにもうあえいでドキドキだからね。それは、実際にはPerlを次の生態圏にそそぎ込む人たちと、それに続く人たちだ。私はPerlをグルー言語として作っただけで、ウェブを作り上げるのに応用したのは別の人たちだ。Perl 6の設計目的の一つに、プログラムを小さく生んで大きく「育てる」のにベストなツールにするというのある。しかし、それを使って、他の人たちは他の生態圏に住んだり、もしくは新たに生態圏を作ることすらするだろう。ウェブで驚かせてもらったように、もう一度驚いてみたいものだ。もちろん、私が完全に間違えている可能性はあるけれどね。

10) Perlを真っ当に評価してもらうためには
kin_kon_karnによる

私は日常的にPerlを使っているプログラマなのですが、役員たちからはPerlを使うのをやめるようにと圧力がかかっています。たくさんの同僚がPerlで開発するのに熟達しており、Perlの方がはやくできるにも関わらず、です。新しい標準はウェブ・サービスやその他糞味噌がいっぱいくっついたJavaなのだそうです。これにはむかつきます。だって、 a)私はPerlびいきで、 b)Javaなんてしょせん流行りモノでそのオーバーヘッドやその内部構造では益体もないような作業にしか使えないことが分かりきっている、からです。

会社の上層部の技術者たちはPerlを真っ当に評価していません。awkの高性能版かウェブ創生期の遺物くらいにしか考えていません。賢明な人たちはこれよりはましですが、でも私たちの管理職にはそういう人はいません。

人びとにPerlをプログラミング言語として真っ当に(再)評価してもらうためにはどうすればいいと思いますか? Perlが広く使われるようになることはあなたのひとつの目標ですか? それともそんなことは気にしていませんか?

ラリー:

ええっと、もしJavaが本当に「流行りモノ」の言語なら、僕たちはJavaを打ち負かすために何もしなくていいはずだけど、現状はどうだい?:-)

それは置くとして、僕の目標は(昔からずっと)Perlをできるだけ役に立つものにすることだ。もし人びとがなにかと理由をつけてPerlを遠ざけるなら、それはPerlが役に立ってないことだと帰結する。とすると、こういう弁護の余地がある。人間は生来そういうものだから、残念なことに、1オンスの囃子立てが1ポンドの理性的な議論を打ち負かすということが往々にしてあるのだ、と。

でも、僕の仕事は囃子立てることじゃなくて、Perlが最大限役に立つように設計しておくことだ。今まで、「真っ当に評価してもらうこと」が直接の目標だったことはない。良かれ悪しかれ、僕は全然まじめじゃなくて、軽率だ。で、Perlにその軽率さが伝染するのが心配だ。でももしPerlがあるべきそのものなら、長い間をかけて自然と真っ当な評価を勝ち取っていくだろう。もし生態圏が自然な状態にあり、かつ自然が真空を嫌うなら、生態圏も真空を嫌うはずだ。僕は、次の10年、20年の間にでっかい吸い込み音が聞こえてくることを期待している。

(追記 2003.3.6 20:20 by GetSet) 肝心のタレコミ者であるyh氏の名前が落ちていた。お詫びとともに訂正させていただく。
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • 校正 (スコア:3, 参考になる)

    by aurora (5149) on 2003年03月06日 21時54分 (#274088) 日記
    1) 「スクリプト言語」あるいは「プログラミング言語」としてのPerl

    > I'm the renaissanciest man that ever lived
    かつてルネッサンス時代に生きていた人

    > Some of the complexity in a Perl 5 program is necessary to the solution, and some of it isn't.
    Perl5 の複雑さは,解消する必要があるものもあるし,そうでないものもある.

    3) 構造化プログラミングとPerl

    > is perl 6 making make perl a structued language like python?
    Perl6 を作ることは.Perl を Python のような構造化言語にするということですか?(やや自信なし)

    > with intricate redundant libraries half of which are deprecated
    複雑で冗長で,半分は(新しいものに置き換えられて)非推奨になったライブラリによって

    > if you write a module or class, it'll automatically default to a stricter mode than it uses for your main program.
    モジュールやクラスを書くと,メインプログラムで使われているより厳密(strict)なモードが自動的にデフォルトになる.

    5) Perl vs 他言語

    > as it did with implicit lexical scoping.
    (以前のバージョン)のレキシカル・スコープがそうだったように

    > inside-out languages like PHP
    PHP のように(コードとデータが)裏返しの言語

    > This is part of a more general class of programming languages in which a peculiar form of processing is assumed by default, such as the pattern/action syntax of awk that assumes an invisible outer loop.
    これは,デフォルトで決まった形式の処理が想定されているような,もっと一般的な種類のプログラミング言語の一部だ. 例えば,awk のパターン・アクション構文では,見えない外側のループが想定されている.

    • by iouri (268) on 2003年03月07日 10時54分 (#274295)
      >3) 構造化プログラミングとPerl
      >
      >> is perl 6 making make perl a structued language like python?
      >Perl6 を作ることは.Perl を Python のような構造化言語にするという
      >ことですか?(やや自信なし)

      Perl6では,PerlをPythonのような構造化言語にしてしまおうとしているのですか?
      くらいが順当かなぁ。原文が元から変な言い回ししてる気がする。

      次に,文中のフットボールは,日本で言うところのサッカーのことです。
      ラグビーやアメフトではありえないと思います。

      あと,『フォニックス』は通常『音声法』または『音声綴り字法』と訳されます。
      言語教育手法の一つなんで,『言語全体を!』という声と対比されてるんだと
      思います。
      親コメント
      • 「フォニックス」という表記を提案した者です。英語教育界では「フォニックス」で定着していると思いますが,一般的には「音声法」みたいに訳出したほうがいいのかな。
        whole language も言語教育手法の一つで,「フォニックス」と書くならこちらも「ホール・ランゲージ」と表記するほうがバランスがとれるかも。
        参考:フォニックスって何? [allabout.co.jp](ホール・ランゲージについても触れてある)

        親コメント
      • by Anonymous Coward
        文中のフットボールは,日本で言うところのサッカーのことです。 ラグビーやアメフトではありえないと思います。
        どうして?アメリカ人が football と言えば、日本で言うアメリカンフットボール以外あり得ないんですが。
    • by Anonymous Coward
      > > I'm the renaissanciest man that ever lived
      > かつてルネッサンス時代に生きていた人

      これは違うでしょう。the renaissanciestは最上級で、that ever livedがついて
      「史上もっともルネサンス的な人」だと思う。もちろん「Rennaisance man」の
      Rennaisanceは形容詞じゃないんだけど、敢えて -iest を付けて言葉遊びしてる。
  • ごみ集め (スコア:3, 参考になる)

    by Anonymous Coward on 2003年03月07日 3時33分 (#274231)

    One of the problems with Java is that they swept a bit too much of the innate complexity of life under the carpet of the libraries.

    の訳の

    Javaの問題のひとつは、ライブラリのカーペットの下にある生来の複雑さを一掃したことだ。

    で、「sweep ~ under the carpet」 はカーペットの下のものを一掃するのではなく、カーペットの「下に」隠し集めるという意味ですね。
    訳すると以下のようになるでしょう。

    「Javaの問題のひとつは、実世界特有の複雑さの多くのかけらを、ライブラリのカーペットの下に隠した込んだことだ。」
  • by numa (4467) on 2003年03月06日 23時00分 (#274126) ホームページ 日記

    翻訳者の皆様,長文の翻訳お疲れさまです。

    ということで,コメントです。3) で,「クリーン・スレート」なる見慣れない言葉が出てきますが,これは wipe the slate clean とか clean the slate という成句がありまして,「過去の過ちやいさかいを水に流す」という意味なのですが,それと同じような意味でしょう。つまり,「Java が clean slate で始まった」,というのも,そういう「過去のしがらみのない」状態から設計されたという意味でしょう。(C++ が C からの互換性という尻尾を引きずっていたのに比べて。)

    • by route99 (7593) on 2003年03月07日 3時09分 (#274229) 日記
      clean slate についてはこのページ [yomiuri.co.jp]に解説がありました。

      clean slate:直訳では「きれいな石盤」となるこのフレーズは「過去のことを忘れて、新しくスタートすること」という意味で使われています。昔の欧米人は石盤に白墨で書き、生地できれいに拭いた時代にさかのぼる言い方です。「過去のことを忘れて、新しくスタートする」はwipe the slate clean になります。
      親コメント
  • # Perlは嫌いだけどラリーさんは好きだな。

    本題。
    7節
    > たったこれだけ。「善き知らせ」は子どもにも理解できる程に単純だが、哲学者には理解できない程に深い。

    「善き知らせ(good news)」は「福音」だと思います。
    • by Anonymous Coward on 2003年03月07日 11時39分 (#274318)
      >「善き知らせ(good news)」は「福音」だと思います。

      かみさんがクリスチャンなので聖書を聞いたり教会のミサに顔を出したりするんですが、
      「福音」(ふくいん)のような文語調(?)は最近の日本語訳聖書ではあんまり使わなくて、
      もっぱら「善き知らせ」「善い知らせ」と言う言葉の方が使われているようです。

      でも、「善い知らせ」と口語調で読んだり聞いたりすると、
      「キリスト教文化を背景にした言葉」という感覚が乏しくなるので、
      「福音」の方が良いんじゃないか?と個人的には思います。

      親コメント
  • ということで (スコア:1, おもしろおかしい)

    by yukichi (12361) on 2003年03月06日 19時57分 (#274025) ホームページ
    こんどはまつもとゆきひろ氏にインタビューをお願いします。
    /.Jで。
  • by Montague62 (1238) on 2003年03月07日 7時29分 (#274245)

    手持ちのリーダーズ英和辞典によると、Renaissance man とは

    ルネサンス的教養人 (幅広い知識と教養の持主; 理想的にはすべての学問および芸術に通暁している人)
    とあります。レオナルド・ダ・ヴィンチみたいなイメージなんでしょう。なので原文の "the renaissanciest man that ever lived" は renaissance を形容詞として使ったもので、
    古今東西最高のルネサンス的教養人
    とか、ルネサンス的教養人が一般的な言葉ではないというなら、
    史上最高の芸術家かつ科学者
    みたいな意味になると思います。

  • コメント数は稼げないかもしれないですが、高く評価したいですな
    --
    # mishimaは本田透先生を熱烈に応援しています
  • >こう来ると$や@や%の記号を取り除くことが、機能リクエストのナンバー1だと思うかもしれない。

    なんかnihonlinux絡みでこんな話があったなと思ってgoogleってみたら……
    スクリプト言語COWのことか。
    http:www.nihonsoft.jp/services_newlanguage.htm
    http://watalab.cs.uec.ac.jp/OBandG/fukuda/cow/index.htm
    (ともにリンク切れ)
  • by yh (6046) on 2003年11月28日 2時36分 (#442296) ホームページ 日記
    「本家インタビュー:Perl開発者ラリー・ウォール」

    この翻訳は多くの方々の共同作業で実現しました。
    ここに記して感謝申し上げます。

    まず、Jadawinさんには共同作業のきっかけを作っていただき、
    問4), 7), 9)を訳していただきました。
    k3cさんには各所で懇切丁寧なコメントを頂戴したほか、
    問6), 10) の訳を頂戴いたしました。
    問6.5)はlimboさんに訳を頂戴いたしました。
    (yhは、問1), 2), 3), 5), 8)を担当し、全般的な調整をいたしました。)

    上記に掲げた方以外にも、訳文の検討、誤訳や専門用語の指摘、感想等のコメントで力をくださった、(コメント順で、)zokkonさん、haresuさん、bnezさん、teltelさん、Katuragiさん、Silphireさん、von_yosukeyanさん、ACさんにも深くお礼申し上げます。
  • by Anonymous Coward on 2003年03月07日 0時04分 (#274163)
    回避されたのでしょうか?今後も翻訳部は活躍しそうなので、システム的な制限はクリアするか、明示されるかが望ましいと思います。<既に32000バイトって明示されたから完了かな?
  • なんで彼は日本語を学んでるんだろう?
    • by HIGE (886) on 2003年03月07日 18時36分 (#274577)
      ええと、手元の「プログラミング Perl 第3版 VOLUME1」 [oreilly.co.jp]の "原著者の言葉" から引用すると、
      私は京都にも行ったことがある。京都は美しい都市である。オライリージャパンの岩田有弘氏がわざわざ東京から来て、2日間にわたって京都を案内してくれた。多くの興味深い神社や仏閣を案内していただいたが、その道すがら彼は日本語についていろいろと面白い話をしてくれた。例えば「橋」と「端」と「箸」の違いについてである。特に気に入ったのは、京都市街から見える山腹にある大きな「大」という文字に関するジョークである。コンピュータサイエンティストたちは、自己参照という概念を発明したのは自分たちだと主張しているが、実はそうではないということがわかった。

      しかし、私が岩田さんからいただいた最大の贈り物は、日本語に対する愛情である。それ以降、私は独学で日本語を学び続けている。
      とのこと。

      これだけじゃちょっと分からないかもしれませんが、ラリー氏はもともと日本好きなようです。
      "原著者の言葉" 前半部分にありますが、「愛車がホンダアコードで、子供に空手を習わせ、日本製のテレビで日本のアニメ(一番好きなのは少女革命ウテナ!!)や戦隊物を見て、奥さんのごきげんをとるのに日本食レストランへ出かける」そうですので。
      親コメント
typodupeerror

私は悩みをリストアップし始めたが、そのあまりの長さにいやけがさし、何も考えないことにした。-- Robert C. Pike

読み込み中...