2004年9月
Steve Yegge / 青木靖 訳
2004年9月
これは駆け足の言語案内だ — Amazon Developers Journalのために今月書いていたのだが、どうもこれを見苦しくないようにする方法を見つけられなかった･･･。
ひとつには、私はどうも粗野で口汚くなりがちで、オフィシャルな趣のあるAmazonの出版物に載せるのは不適切に思えた。それでかわりに誰も読まない自分のブログに押し込めてしまうことにした。読んでるのはあなたくらいのものだよ。どうも!
もうひとつ言うと、これは本当に書きかけのものであり、そこかしこの断片を集めたものでしかない。全然磨き上げられていない。これもブログエントリにする理由になっている。ブログなら別に良質である必要も完全である必要もない。単に私が今日考えたことというだけのものだ。ではお楽しみを!
この駆け足の案内では、C、C++、Lisp、Java、Perlをカバーしている(私たちがAmazonで使っている言語全部だ†)。Rubyは単に私が好きというだけの理由で入っている。それからPythonも入っているが、これは･･･ああ、ここで先走って説明してもしょうがないね。
†この文章は読者としてAmazon社員を想定していた。
あなたは単純にCを知っている必要がある。なぜか? あなたの使ったことのある世界のコンピュータは、実用的な目的のものについていえば、すべてフォン・ノイマン・マシンだ。そしてCというのは、フォン・ノイマン・マシンの機能を記述するための軽量で表現力の高いシンタックスなのだ。
フォン・ノイマン・アーキテクチャというのは、CPUに、RAMに、ディスクに、バスという、あなたが日常で使っている標準的なコンピュータアーキテクチャのことだ。マルチCPUでもこのことは基本的に変わらない。フォン・ノイマン・マシンは、抽象的な計算実行モデルとして有名なチューリングマシンが、使いやすくコスト効率 の良いものとして1950年代に実現されたものだ。
別な種類のマシンも存在する。たとえばLispマシンというのがある。これはラムダ計算に基づくプログラミング記法であるLispが1950年代に実現されたものだ。ラムダ 計算というのも計算実行モデルの1つだ が、チューリングマシンと違い、ラムダ計算は人間によって読み書きできる。しかし2つのモデルは能力の点では等価だ。どちらもコンピュータに可能なことを正確にモデル化している。
しかしLispマシンというのは、ガレージセールを別にすると、あまり見かけない。フォン・ノイマン・マシンが人気レースで勝利したのだ。ニューラルネットワークやセルオートマトンをうまく現実化したコンピュータというのも存在するが、これもまた人気がない。少なくとも今のところは。
だからあなたはC言語を知る必要がある。
C言語はまた、それがUnixの書かれている言語であるという意味でも知っておく必要のある言語だ。それに偶然ながらWindowsと、そのほか実質的にすべてのオペレーティングシステムがCで書かれている。それというのも、それらのOSはみなフォン・ノイマン・マシンのためのOSだからだ。他に何の言語を使うって言 んだ? C言語から大きくかけ離れた言語というのは、ハードウェアの実際の機能とあまりに離れているため、十分なパフォーマンスを出すことができない。少なくともそれらのOSが書かれた20世紀においてはそうだった。
あなたはまたLispも知る必要がある。別に実際の仕事に使う必要はない。もっとも、多くのGNUアプリケーションにはLispは思いがけず役に立つものなのだが。特にLispの小さく純粋な方言であるSchemeを学ぶといい。GNU版のScheme実装はGuileと呼ばれている。
MITとバークレーでは新入生にSchemeを1学期か2学期教えている。学生はなんでそんな奇妙な言語を学んでいるのか見当もつかない。正直なところ、Schemeは最初に学ぶ言語としてはひどいものだ。そしておそらくは2番目としても。あなたはいつかそれを学ぶべきだが、最初と2番目は避けておいた方がいい。
Lispを学ぶのは簡単ではない。大きな飛躍がいるのだ。CみたいなプログラムをLispで書けるというのでは十分でない。そんなのは無意味だ。CとLispはスペクトルの反対の端に位置している。他方が上手く扱えない領域で大きな力を発揮するのだ。
Cがコンピュータがどう動作するかのモデル化に最も適した言語とすると、Lispは計算というものがどう振る舞うかをモデル化するのに最も適した言語だ。ほんとのことを言って、Lispについて多くのことを知る必要はない。一番シンプルでクリーンなSchemeを使い続けることだ。他のLisp方言はライブラリやらツールやらを備え、C++やJavaが持つような大きく複雑なプログラミング環境へと成長している。そういう部分については知っている必要はない。ただSchemeでプログラムを書ける必要がある。The Little Schemer と The Seasoned Schemerの練習問題を自力ですべて解ければ十分だと思う。たぶん。
しかし日常のプログラミングに使う言語ということであれば、ライブラリとかドキュメンテーションとかツールサポートとかOSとの親和性とかリソースとか、そのほかたくさんのことに基づいて選ぶ必要がある。それはコンピュータはどう動くのかということとはあまり関係なく、人はどう動くのかということ と大いに関わっている。
今でも多くの人がプログラムを素のCで書いている。たくさんのものをだ。あなたはCを知っている必要があるのだ!
C++は地上でもっともバカな言語だ。すごく感覚が鈍いという意味で。C++は自分自身のことがわからない。イントロスペクティブでないのだ。Cも同様だが、Cは別に「オブジェクト指向」なわけではない。そしてオブジェクト指向であるということの小さからぬ部分は、プログラムが自分自身のことをわかるということなのだ。オブジェクトはアクターだ。だからOO言語はランタイムリフレクションとランタイムタイピングを 備えている必要があるのだが、C++は本当にはそれを持っていない。あなたが使ったやつは違うのだ。
Cについて言うと、Cの上にイントロスペクションのように振る舞うツールを作れるCコンパイラを書くのはとても簡単だ。一方、C++は本質的にパースできない。だからあなたが、たとえば仮想関数のシグネチャを教えてくれたり、コードをリファクタリングしてくれたりするような賢いツールを書こうと思うなら、誰か他の人の書いたツールセットを我慢して使うしかない。あなたはまずパースできないはずだ。そしてC++をパースするツールセットというのはどれも最低だ。
C++はバカであり、バカな言語で賢いシステムを書くことはできない。言語は世界を形作る。バカな言語はバカな世界を作る。
コンピューティングはすべて抽象化に基づいている。低いレベルのものの上に、高いレベルのものが作られる。分子から都市を造ることはできない。あまりに抽象度 のレベルが低いものを使おうとするなら、災難に見舞われることになる。
そして私たちは災難に見舞われている。
Cでまっとうに書くことのできる一番大きなものはオペレーティングシステムだ。そしてそれは実際のところそんなに大きなものではない。それが大きく見えるのはアプリケーションのためであって、カーネルは小さなものだ。
C++で書くことのできる一番大きなものは･･･やはりオペレーティングシステムだ。まあ、幾分大きめの。3倍大きいということにしておこう。あるいは10倍でもいい。しかしオペレーティングシステムのカーネルはせいぜい100万行というところだろうか? だからC++でまっとうに書ける一番大きなシステムは1000万行で、そのあとは崩れていき、コントロールできる見込みはなくなり、「リトル・ショップ・オブ・ホラーズ」の工場みたいなことになる。食わせてくれーー・・・
コンパイルできるところが限界だ。
うちには5000万行のC++コードがある。いや、今ではもっと増えている。もはやどれくらいになっているのかわからない。去年のクリスマス、つまり9ヶ月前には5000万行だった。それから4半期ごとに800万行ずつ増えている。増加率自体も増えている。やれやれ。
ここでは何かやるのにいつまでも時間がかかる。以前あるAmazonのエンジニアが、我々のコードベースをこう形容した。「巨大なクソの山で、かつて見たこともないほどでかく、その中心まで潜って 行くのが我々の仕事であり、そのたびに何かを直す羽目になる」
それが4年前の話だ。そのエンジニアはもっと快適な場所へと去ってしまった。残念なことだ。彼は本当に優秀な人間だったのだ。
これはすべてC++の問題だ。口答えしない。そうなのだ。私たちは世界でもっともバカな言語を使っている。それはメタ-バカとでもいうたぐいのものだ。そう思わない?
とは言え、C++コードでいいものを書くことは明らかに可能だ。それはつまり、ほとんどCのコードに、いくらかのC++の機能が、最低限だけうまく使われているような場合だ。しかしそういうこと には決してならない。C++はすごい遊び場であり、そのすべてを知るとすごく賢くなった気分になる。だからあなたはそのすべてを使おうとすることになる。しかしそれはうまくやるのが本当に難しいのだ。なぜならC++はそもそもにおいてクズ言語だからだ。たとえあなたが優秀であったとしても、結局は台無しになってしまう。
こんなことを言うのが異端であるのはわかっている。固有名詞の異端だ。私だって大学生のときはC++が好きだったのだが、それは私がそれしか知らなかったからだ。私の言語の教授のクレイグ・チェインバーズがC++は大嫌いだと言うのを聞いたとき、「どうして? 私はこんなに気に入ってるのに」と思った。そしてSTLの作者がOOPは嫌いだと言ったという話を聞いたとき、私は彼がどうかしてると思った。OOPを嫌うなんてことがありうるだろうか? こともあろうにSTLの作者が?
満足を育むのは、多くの場合コンピュータ言語自体ではなく、馴染んでいるということによってだ。慣れ親しんだもので満足してしまう前に、もっといい言語のエキスパートになる必要がある。
だから私がC++について言ったことが気に入らないなら、もっといい言語のエキスパートになることだ(私はLispをおすすめする)。そうすればあなたは私に反論する準備ができたことになる。しかしあなたはそうしないだろう。私はあなたを引っかけたのだ。そのときには、あなたはもうC++のことが好きではなくなっている。そして私が引っ かけて元好きだった言語を嫌いにさせたことに腹を立てるかもしれない。だからあなたはたぶん私が今言ったことは単に忘れてしまった方がいいのだ。C++はすごいよ。本当に。すばらしいとしか言いようがない。私の言ったことは忘れてほしい。問題ないって。
(あなたがここの常連だったとしても、次のやつには驚くだろうと思う。)
Amazonが始まった当時はすごいエンジニアたちがいた。私は全員知っていたわけではないが、何人かは知っていた。
例がほしい? シェル・カプラン。すばらしい。グレッグ・リンデン。すばらしい。エリック・ベンソン。Amazonに来る前から有名だった。彼もすばらしい。
彼らはObidosウェブサーバを書いた。ObidosがAmazonを成功させたのだ。Obidosがしょぼくなったのは後になってからのことだ。クズを作るエンジニアやWeb開発者、主としてフロントエンドの連中——クズを早く作ることでマネージャを喜ばせるスケジュールに従って動 く連中——がObidosをまずいものにしたのだ。言ってみれば川の流れを詰まらせてしまったのだ。しかしObidosはAmazonの初期の成功の礎石だった。
初期にいたすばらしい人たちは、Amazonの神聖なるソースリポジトリに2種類の言語しか入れることを許さなかった。CとLispだ。
信じられない?
彼らはみんな、もちろんEmacsを使っていた。エリック・ベンソンはXEmacsの作者の1人だ[1]。世界の最高のエンジニアたちはみんなEmacsを使っている。世界を変えるようなタイプの人たちは、ということだ。あなたの隣のキュービクルにいるすごい彼女のことじゃない。向こうの部屋にいるすごいフレッドのことでもない。我々の分野で最高のソフトウェア開発者たち、業界の様相を変えるような人たちのことを言っている。ジェームズ・ゴスリング、ドナルド・クヌース、ポール・グレアム[2]、ジェイミー・ザウィンスキー、エリック・ベンソン。本物のエンジニアは皆Emacsを使う。Emacsをうまく使えるためには相当頭が良くなければならないが、マスターすれば驚くほど力を与えてくれる。信じないなら、ポール・ノードストロムが仕事しているとき肩越しにのぞき込んでごらん。Visual Hoge.NETみたいなIDEしか使ったことのない人は本当に驚くことになると思う。Emacsは100年のエディタだ。
シェル、エリック、グレッグ、その他私が直接一緒に働く幸運に恵まれなかった人たち。彼らはC++を使うことを認めなかったし、Perlを使うことを認めなかった(その意味ではJavaも)。彼らはそんなにバカじゃない。
今では私たちが書いているのはみんなC++にJavaにPerlだ。先輩たちはもっと快適な場所へと移ってしまった。
シェルはMailmanをCで書き、カスタマサービスの連中がそれをLispでラップした。Emacs-Lispだ。あなたが年季の入ったAmazon社員で、おそらく非技術系で、顧客をハッピーにするのが仕事だというのでもない限り、Mailmanのことは知らないだろう。それはあなたの書いたバカな機能がおかしくなって(C++で書いたから)、ユーザをうんざりさせることになり、幸福さを回復させるために直さなければならなくなった、というような間接的な仕方ではない。私が言ったのは、直接的にということだ。あなたは彼らと話さなければならなかった。私たちの愛すべき、教養がなく、雄弁で、善良で、希望を持ち、混乱し、役に立つ、怒っ ている、幸せなユーザたち。私たちから製品を買う本物の人間。私たちの顧客。それならあなたはMailmanを知っているだろう。
Mailmanはカスタマサービス部門で顧客からのメールを処理していたアプリケーションで、それが使われていたのは4年か･･･それとも5年か? とにかく長い間だ。Emacsで書かれていた。みんなそれが好きだった。
みんな今でもそれが好きだ。今日でも、非技術系の連中から、Mailmanがなくなってどんなに残念かという話を長々と聞かされる。別に君たちのことをけなしているわけじゃない。去年のクリスマスに、私はAmazonのパーティに出た。ビジネスの連中ばかりのパーティで、なんで私が招待されたのかわからなかった。彼らはみんな、私や、私が一緒に溶鉱炉——Amazonのボラールームで働いている連中より、美しく魅力的だった。若い女性の4人組が、私がカスタマサービス部門にいたことを知って詰め寄ってきて、自分たちがいかにMailmanとEmacsを恋しく思っているかと、そしてArizona(私たちが何年もかけて開発しているJSPによる代替アプリケーション)にはいまだ同じことができないのだと、15分にも渡って言い続けた。
これはほんとにシュールだ。彼らはエッグノッグにアルコールを入れてたんじゃないかしら。
シェルは天才だ。Emacsは天才だ。非技術系の人たちでさえEmacsを愛している。私は今Emacsでタイプしている。私が自主的に別なエディタを使うことは決してない。この惑星上で他には見つけられないタイピングのショートカットやテキスト編集機能が生産性を押し上げてくれるというだけじゃない。私は自由形式の文章であれば、Emacs上で1分間に130から140語を間違いなしでタイプできる。自分で書いたタイピングテスト用のEmacsアプリケーションで計測したのだ。しかしEmacsにはそれ以上のものがある。
Emacsには名のない資質があるのだ。
私たちはMailmanを引退させた。それは私たちの持つ名のある資質のためだ——すなわち最低さだ。私たちは最低だ。私たちはそれをうまくやれるほどEmacs-Lispが達者な人間を見つけられなかった。今なら簡単かもしれない。AmazonにはEmacs Lispハッカーがいっぱいいる。しかし当時は、カスタマサービスアプリケーション部門は誰からも見向きもされず、手持ちのものでやれることをやるしかなく、そしてEmacs-Lispができる連中はあまりいなかった。しばらくの間、オライリーの「シマウマ」本(GNU Emacs拡張ガイド)の著者のボブ・グリックステインをMailmanのために契約で雇いさえしていた。彼はセキュリティ部門のビルにある小さなオフィスで仕事していた。
カスタマサービスアプリケーション部門はAmazonの最初の「ピザ2枚のチーム」†だった。彼らは完全に自律的だ。当時も今も。誰も彼らと話さないし、誰も彼らを助けない。彼らはすべて自分で作っている。彼らのところにはWeb開発者はおらず、サポートエンジニアはおらず、スワットはおらず、ただ堅実なエンジニアと良き指導文化があった。そしてそれが彼らの必要としたすべてだった。
†ピザ2枚で済む少人数のチーム
しかし彼らはMailmanを引退させた。ああ。あああ。私は今でもあれがなくなったのが残念だとみんなが言っているのを聞く。パーティにおいてさえ。
それでもカスタマサービスアプリケーション部門はAmazonの他の部署よりLispハッカーの割合は多いんじゃないかと思う。彼らは別にLispをよく使っているというわけではないが、ただエリック・レイモンドの言うように、たとえそれであまりプログラムを書かないとしても、Lispを学ぶことはすばらしい経験となり、あなたを優れたエンジニアにしてくれるのだ。その後の人生に渡ってずっと。
宗教はもはや大衆の麻薬ではなくなったようだ、カール。今ではIDEだ。
Javaは過去10年においてコンピューティングの世界に起きた最良かつ最悪のことだ。
Javaは一方ではC++コーディングのつまらなくて間違いやすい細部から人々を開放した。境界エラーはなくなり、コアダンプはなくなった。投げられた例外はエラーの起きた正確な行を指し示し、それは99%の場合には正しい。オブジェクトは要求に応じて自身の気の利いた表示を行う。などなど。
他方で、Javaというのは言語、仮想マシン、巨大なクラスライブラリのセット、セキュリティモデル、ポータブルバイトコードフォーマットであるというのに留まらず、宗教なのだ。だからJavaをあまりに愛している人というのは信用することができない。いいJavaプログラマを採用するというのは難しいことなのだ。
しかしJavaはソフトウェアエンジニアリング一般ということでは大きな前進だった。
C++からJavaへ移行するのは単に構文を変えるということではない。それは衝撃的なほどに大きなパラダイムシフトであり、本当に理解するようになるまでには時間がかかる。それは突然 アシスタントを持つようになったようなものだ。副社長たちがいつでもミーティングに出ていて、それでいながら会社の状況を理解しており、クールなドキュメントを書いたりそのほかのことをしているのを知っているだろう。副社長というのは実際は自分が2人の正社員であるということを忘れがちだ。彼ら自身と、彼らのアシスタントだ。アシスタントを持つことで、解決しなきゃならない問題について考えることから解放される。アシスタントを持たないなら、時間の半分はつまらない作業のためにつぶすことになる。Javaに切り替えることは、2人のプログラマになることだ。1人はあなたがもはや気にかけなくて良くなったことの面倒を見、もう1人が問題領域にフォーカスする。これはびっくりするくらい大きな変化だ。そしてこれはあなたが極めて速やかに慣れる類の変化でもある。
ジェイミー・ザウィンスキーが有名なアーティクル"Java Sucks"で書いている。「最初にいい点を挙げると、Javaはfree()する必要がない。その他のことはすべて大したことではないとためらわずに言える。この一点によって、私は他のほとんどあらゆることを、それがいかにひどかろうが許すことができる。この一点によって、この文章にある他のすべてがほとんど些細なことになってしまうのだ」
ジェイミーのアーティクルは1997年に書かれた。これはJavaの世界では大昔だ。彼がそれを書いてからJavaは大幅に改善された。今では彼が文句を言ったことの一部が修正さえされている。
しかし多くのものは修正されずにいる。Javaはいまだ言語としては最低だ。しかしジェイミーが指摘しているように、「今日における最高の言語というのは、言ってみれば、私たちが現実世界で扱わなければならないまったくへぼな負け犬言語の中にあって 、かろうじて許容できるもの、というレベル」なのだ。
ほんとに、あなたはこれを読むべきだ。
Javaは言語自体を別にすれば、あらゆる面で本当にすばらしい。JWZが苦言を呈しているのもほとんど言語自体についてだ。そしてそこには不平を言うべきところがたくさんあるのだ。言語が最低ならライブラリにできることも限られる。本当だ。あなたは多くのことについて私より知っているかもしれないが、ライブラリが最低な言語を本当に救うことはできないことを私は知っている。Geoworksでの5年間のアセンブリ言語の地獄が私にそのことを教えてくれた。
C++と比較すれば、Javaは言語として同程度だ。いや、今のなし。ずっといい。文字列があるもの。文字列のサポートがお粗末な言語なんていったいどうやって使えるんだ?
しかしJavaはC++にあるいくつかの素敵な機能を欠いている。たとえば(スタックオブジェクトの)参照渡し、typedefマクロ、オペレータオーバロード。ときどき役に立ってくれるものたちだ。
ああ、それに多重継承。私はこの年になってようやくその価値を認めるようになった。私の頑固者のエルフがポリモーフィズムのドグマへのいい反論になると思うなら、多重継承か、少なくともRubyスタイルのミックスイン や自動デリゲーションがなぜ必要なのかのいい例をいくつか教えてあげられる。いつか私にGlowing Sword(炎の剣)やCloak of Thieving(盗人のマント)について尋ねてほしい。インタフェースは最低だ。
ゴスリングでさえ、何年か前、すべて始めからやり直すとしたら、インタフェースは使わないだろうと言っていた。
しかしまさにそれがJavaの問題なのだ。ジェームズがそう言ったとき、みんなショックを受けた。私はそのショックウェーブを感じることができた。Sunのマーケティングと法務の連中が作戦行動を起こして彼を黙らせ、否定し、そうじゃないという話にしたのだ。
Javaの問題は人々がマーケティングハイプによって盲目になっているということだ。これはC++の問題であり、Perlの問題であり、人気のある言語すべての問題 であって、しかも深刻な問題なのだ。言語はハイプなしに人気になることはないからだ。だから言語デザイナが言語が完璧にデザインされてないかもしれないと無邪気に口にするなら、馬用のトランキライザーを打って言語デザイナを黙らせ、カンファレンスを閉鎖するのだ。言語は生き延びるためにハイプを必要とする。私はただ人々がそれで目が見えなくならないことを願っている。
私はOOP入りのクールエイドを飲んだ。私自身ハイプをオウム返しして言っていた。Amazonで働きはじめたとき、私は学んできたあらゆる決まり文句や賛美歌やブードゥーのまじないをそらんじることができ、それを思考や経験のかわりにしていた。多重継承は悪だ。みんなそう言っているから。オペレータのオーバロードは悪だ。みんなそう言っているから。私はその理由をぼんやりと理解してはいたが、本当にではなかった。それから私は最低なのは多重継承ではないと認識するようになった。最低だったのは私だ。今でもそうだが、年々ましになっている。
先週面接した人が、多重継承は悪で、それは、たとえば人のクラスを、頭と腕と脚と胴体のクラスの多重継承にするというのはひどいからだと言っていた。彼は正しく、同時に間違っていた。その多重継承の状況は、確かに悪だ。しかしそれは全部彼の問題だ。遠くにいればただのバカだが、玄関から入れてやるなら悪になる。
まずい開発者は、これは世界の開発者の多数を占めるわけだが、どんな言語を与えようとまずいコードを書くのだ。
そうは言っても、多重継承は決して楽なものではない。ミックスインの方が良いソリューションであるように思えるが、誰もまだこの問題を完全には解決していない。しかし多重継承がないにしてもJavaは依然C++より優れており、それは私がいかにがんばったところで、私はどこかでコードの書き方のわからない連中に取り巻かれることになり、彼らにはC++よりはJavaを使わせる方がはるかに害が少ないのだ。
加えて、Javaにはコアの言語よりもずっと多くのものがある。そして言語自体も、氷河のようにのろいにせよ進歩していく。だから希望はある。それは私たちがAmazonで使うべきものだ。
ただ注意深くする必要がある。どんな言語でもそうだが、言語環境についてはよく知っているが、テイストやコンピューティングやそのほかの重要なことについてはほとんど知らない人がよくいるからだ。
不確かな場合には、多言語が使える人、J2EEやEJBのような大きくあやふやなフレームワークを嫌っている人、そしてEmacsを使っている人を選ぶことだ。これはいい目安になる。
さて、Perlだ。どこからはじめよう?
Perlとは古い友達だ。Perlと私の付き合いはずっと昔にまで遡る。私がPerlで書くようになったのは、たぶん1995年頃で、それから10年くらいPerlは私の要求 によく応えてくれた。
Perlは10万マイルとか20万マイルとか乗ってきた古い自転車みたいだ。そしていつでもそれには何かしっくり馴染むものがある。たとえ5ポンドの軽さで尻がそんなに痛くならないもっとモダンな自転車に乗り換えていたとしても。
Perlに人気があるのには3つの理由がある。
Perlよりも「良い」言語はある——そんなのはたくさんある。「良い」を「いかれていないこと」と定義するなら。Lispに、Smalltalkに、Pythonに、ああ、Perlより「良い」言語だったら20や30すぐに名前を挙げられる。Perlは夏の台湾の通りの上で破裂したマッコウクジラだ。はらわたがそこら中に飛び散って、車や自転車や歩行者を覆っている。それがPerlだ。本当にチャーミングだ 。
しかしPerlは最近まで他のどの言語も持っていなかったものを持ち、それがはらわたが露出していることを補っていた。破裂したクジラからだっていろんなものが作れるのだ。香水だって作れる。すごく有用なのだ。Perlもそうだ。
他の言語(LispとSmalltalkは中でも特筆に値する)はみんなオペレーティングシステムが存在しない振りをしようとして、リストがすべてだとか(Lisp)、オブジェクトがすべてだ(Smalltalk)と言っているのに対し、Perlはまさにその逆のことをしている。ラリーが言っている。「Unixと文字列処理が、物事をやり遂げるために必要なすべてだ」
そして多くのタスクに対し、これはまったくもって正しいのだ。だからPerlはUnixとの統合と文字列処理においてこの惑星上の(1つを除く)どの言語よりも優れている。そしてその例外となる1つが舞台に登場したのはごく最近のことで、それはゴジラの国でのことだ。これについては後で話そう。
残念ながら、ラリーはUnix統合と文字列処理にあまりにフォーカスしすぎた。そしてリストやオブジェクトについては、ちゃんと実装するのが手遅れになるまでまったく目を向けなかった。実際、いくつかの基本的な誤りが初期におけるPerlの･･･なんていうか、クジラのはらわたに「デザイン」という言葉を使うのはためらわれるのだが、それはPerlの「ライフサイクル」の問題だ。この誤りによってリストやオブジェクトを正しく取り扱うことが非常に難しくなっており、Perlは真性のルーブ・ゴールドバーグ・マシン†へと進化することになった。少なくともリストやオブジェクトを使おうとするなら。
†http://www.rube-goldberg.com/
リストやオブジェクトだってすごく重要なんだよ、ラリー!
Perlがリスト処理をできないのは、リストを自動的に平坦にするという救いがたく愚かな決断をラリーが初期にしたことによる。そのため(1, 2, (3, 4))は不思議なことに(1, 2, 3, 4)に変わってしまう。あなたはこんな風になってほしいと思ったことはないだろう。しかしラリーがある日たまたま何かの問題でそうなるのが都合が良かったため、それ以来Perlのデータ構造はまったくの破裂したクジラとなってしまったのだ。
今では、Perlの本にせよ、チュートリアルにせよ、PowerPointにせよ、少なくとも3分の1の時間は「リファレンス」の勉強に費やすことになる。これはラリーのリスト展開病に対する救いがたい、破綻した、ゴールドバーグ的修正なのだ。しかしPerlのマーケティングは驚くほど優れており、リファレンスはかつて経験した中で最良のものみたいにあなたは感じている。何に対してもリファレンスを取ることができる! 楽しい! においだっていいし!
Perlでオブジェクトが使えないのは、ラリーが決して本当にオブジェクトを信じたことがないためだ。それはそれでいいのかもしれない。私自身オブジェクトを信じているのかあまり確信がない。しかしそれならなぜオブジェクトを追加したりしたのか? PerlのOOは中途半端なアドオンで、Perlコミュニティに決して受け入れられてはいない。文字列処理やUnix統合のように感心するものではないのだ。
そしてもちろん、Perlにはそのほかにもたくさんデザイン上の奇妙なところがある。たとえば「コンテキスト」を見るといい。それはラリーがシェルスクリプトからコピーしたN変数ネームスペースやシジルによるデリファレンスのようなおかしな決断のぞっとする副産物だ。Perlでは、すべてのオペレータ、すべての関数、すべての操作が、その「コンテキスト」に従い、6つのうちのランダムな1つの仕方で振る舞う。与えられたコンテキストにおいて特定の操作がどう振る舞うかを支配するルールやヒューリスティクスというのは存在しない。あなたは単にすべて暗記しておくしかないのだ。
例がほしい? スカラーコンテキストでハッシュにアクセスすると、分子が割り当てられたキーの数、分母がバケットの数となっている分数を内容とする文字列が得られる。クジラのはらわただ。そう言ったでしょ。
しかし、最近まで、Perlみたいに仕事が成し遂げられるものは他になかったのだ。
15年かそこらごとに、プログラミング言語はより優れた言語に置き換えられてきた。CはC++で置き換えられた。パフォーマンスが要求されるがデータ型もどうしてもほしいという大規模アプリケーションを開発する人々の間 では少なくともそうだ。C++はJavaで置き換えられ、Javaもまた何かより優れたもので置き換えられるだろうことは疑いない。7年のうちに——C++の置き換えを終えてから7年後にだ。この置き換えはまだ完全には成し遂げられていないが、それは主としてJavaがデスクトップに遍く行き渡るまではMicrosoftが足止めさせることができたためだ。しかしサーバサイドアプリケーションでは、C++は基本的にすでに退場している。
Perlもまた、間もなくなくなる。それは新しいRubyと呼ばれる言語がついに英語に翻訳されたためだ。そう、それはこともあろうに日本で作られた。これにはあなた同様みんな驚いている。日本はハードウェアと製造業では知られているが、ソフトウェア開発では知られていない。 どうしてなのか誰にもわからないが、私の考えでは、それはタイピングの問題のためだと思う。1万種の文字があるアルファベットを使っていながら彼らが十分速くタイプできるとは、私には想像できなかった。しかしEmacsは多言語サポートを数年前に手にしたので、今では彼 らがすごく速くタイピングするのを想像できる。(そして彼らはEmacsを使っている——実際EmacsのMuleサポートは主として日本の人たちによってなされたのだ。そしてそれは非常に信頼性が高い。)
何にしても、RubyはPerlのいい部分をすべて盗んだ。実際、Rubyの作者のMatz(私の記憶が確かなら「まつもとゆきひろ」という名前だが、彼は"Matz"で通っている)は、Perlからちょっと盗みすぎたと思っているかもしれない。クジラの内臓が少し靴に入ってしまっ ている。しかしほんの少しだ。
おおよそのところ、 RubyはPerlの文字列処理とUnix統合をそのまま取り入れた。つまりシンタックスまで含めて同じなのだ。だから他の何かを待つまでもなく、すでにPerlの最良の部分を手にしているのだ。そして これは出発点としては素晴しいものだ。特にPerlの他の部分を取り入れないならば。
しかしその後Matzは最高のリスト処理をLispから取り入れた。そして最高のOOをSmalltalkその他の言語から。そして最高のイテレータをCLUから。あらゆることの最良の部分をあらゆるところから取り入れたのだ。
そしてどうにかしてそれらが一緒に動くようにしていて、それがあまりにうまく行われているので、そこにそんなものがあるとは気付かないくらいだ。私はRubyを、私が知る30か40の他の言語のどれよりも早く学ぶことができた。RubyをPerlよりも快適に使えるようになるのに3日しかかからなかった。8年のPerlハッキングの後においてだ。Rubyは非常に一貫性が高く、 じきに物事がどう動くか推測できるようになる。そしてほとんどの場合正しく推測できる。それは美しい。そして楽しい。そして実用的だ。
言語が自転車だとしたら、Awkは赤い子供用自転車で、白いバスケットがあり、ハンドルの端に吹き流しがついている。Perlはビーチクルーザーで(それがどんなにクールだったか覚えている?)、Rubyは7,500ドルのチタン製マウンテンバイクだ。PerlからRubyへの飛躍はC++からJavaへの飛躍と同じくらい大きい。しかも悪くなっているところは何もなく、Rubyは本質的にPerlの機能の真性のスーパーセットになっている。一方Javaの方は人々がない のを残念に思うC++の機能がいくつか省かれており、本当の代替にはなっていない。
いつかRubyについてまた書こう。私は最初に霊感を必要とする。ホワイの(感動的)Rubyガイドを読むといい。これは傑出した作品だ。本当に。ぜひ読んで。驚くべきものだ。私にはこのようなものを生み出せる精神を理解することはできないが、しかしこれは可笑しく、感動的で、Rubyのすべてが書かれている。まあ言ってみれば。読めばわかるよ。
Pythonはどうか? 素敵な言語で、舞台袖でずっと我慢強く待ち続けていた。Pythonのコミュニティは長い間、赤いピルを飲んでPerlのマトリックスから目覚めた人々の避難所だった。
彼らはSmalltalkの人たちと同じだ。SmalltalkはC++に取って代わるのを長い間待ち続け、そしてJavaが現れて彼らを完全かつ恒久的に閉め出し てしまった。Rubyがまったく同じことを、今、Pythonに対して行っている。事実上一夜にして。
Pythonは世界を支配できたかもしれないが、致命的な欠陥が2つある。ホワイトスペースの件と、永久凍土の件だ。
ホワイトスペースの件というのは、Pythonがインデントをブロックのネストの定義に使っていることだ。これにより、すべてに対してある仕方でインデントを付けなければならなくなるが、そうしている理由は誰の書いたコードも同じように見えるようにするためなのだ。驚くほど多くのプログラマがこれを忌み嫌っている。自由が侵害されているように感じるのだ。ショットガンフォーメーションや難解なワンライナーを使う基本的人権をPythonが踏みにじっていると感じるのだ。[3]
Pythonの作者のGuido Van Rossumはまた、間抜けな技術的失策を初期に犯している。ラリーの失策ほど甚だしいものではないが、それでもいくつか本当にひどいのがある。たとえばPythonはもともとレキシカルスコープを持っていなかった。そして動的スコープも持っていない。動的スコープにも問題はあるのだが、それなりには機能する。Pythonはグローバルスコープとローカル(関数)スコープ以外のスコープを何も持っていない。だからPythonには「本物の」OOシステムがあるのだとしても、クラスは自分のインスタンス変数にさえアクセスできない。あらゆるインスタンスメソッドに対し"self"パラメタを渡す必要があり、そうやってインスタンスデータにself経由でアクセスするのだ。だからPythonの中のものはすべて、self、selfself、selfselfself、selfSELFselfSELF__SELF__であり、たとえあなたがホワイトスペースの問題を気にかけないとしても、これはあなたの頭をおかしくするだろう。
しかし私の意見では、本当にPythonを殺し、メインのスクリプト言語となる望みを、あるいは何であれメインの言語となる望みを絶ったのは、永久凍土の問題なのだ。人々はいまだ埋め込みインタプリタにTclを使っている。どのような面から見てもTclよりPythonの方が遥かに優れているというのに——ただし永久凍土の問題を別にすれば。
永久凍土の問題とは何かって? 私はここですごく品のないことを書いてきたが、しかしPythonを使うのは実際とても快適であり(その欠点を大目に見られるなら)、私はもはやパイソニスタたちを叩くのがそんなに面白いことだとは思わなくなった。「永久凍土の問題」というのは、単に彼らが傾向として、その、冷たかったということだ。なぜか? それは彼らがホワイトスペースの問題について指摘されるのにうんざりしていたためなのだ!
私はそれがPythonがPerlのレベルの人気をけっして得られない理由だと考えている。しかし私が単に想像しすぎなだけかもしれない。
私はこれを本当にADJのアーティクルとして書きたいと思っていた。少なくともそういったたぐいのものとして。しかし何かの理由で、私の本当の感覚は午前3時から6時の間の不眠症の発作の間にしか出てこないらしい。さあ、寝る時間だ! 次のミーティングまで2時間しかない。
(2004年9月に公開、2006/3/28にマイナーな修正)
1. エリックは、Lucidでジェイミー・ザウィンスキーと一緒に働いていたときに、ほとんどすべてをジェイミーが書いたのだと言っている。
2. 多くの人がポール・グレアムはviを使っていると指摘してくれた。驚きだね!
3. 記録のために言っておくと、私自身はホワイトスペースの問題を全然気にかけていない。そんなことのためにPythonを嫌うのはばかげたことだ。私が言っているのは、驚くほどの割合の*他の*プログラマたちがそれを嫌っているということだ。
| home rss | Steve Yeggeについて |
オリジナル: Tour de Babel |