普通のやつらの上を行け ---Beating the Averages---

著者:Paul Graham
Copyright 2001 by Paul Graham


これは、Paul Graham: Beating the Averages を、原著者の許可を得て翻訳・公開するものです。

プロジェクト杉田玄白正式参加テキスト。

<版権表示>
本和訳テキストの複製、変更、再配布は、この版権表示を残す限り、自由に行って結構です。
(「この版権表示」には上の文も含まれます。すなわち、再配布を禁止してはいけません)。
Copyright 2001 by Paul Graham
原文: http://www.paulgraham.com/avg.html
日本語訳:Shiro Kawai (shiro @ acm.org)
<版権表示終り>

文中、Eric Raymondの "How to become a hacker" からの引用部分の訳は 山形浩生氏の訳を 引用させていただきました。

Paul Graham氏のエッセイをまとめた『ハッカーと画家』の 邦訳版が出版されました。
出版社の案内ページ Amazon.co.jp サポートページ

2001/5/2 翻訳公開
2001/5/3 原文の改訂を反映
2001/5/12 武井伸光さんからの誤記の訂正を反映
2001/11/20 ``pointy-haired boss'' の訳を訂正
2002/6/10 プロジェクト杉田玄白正式参加に伴い版権表示を整備
2005/1/21 中西通雄さんより、latticeの訳について教えていただいたので反映


(この記事は2001/3/25にケンブリッジで開催されたFranz Developer Symposium で行った講演をベースにしている。2001/5/3版)

1995年の夏、私は友人のロバート・モリスとともにViawebというベンチャー企業を 立ち上げた。エンドユーザーがオンラインストアを自分で作ることが出来るソフトウェアを書く、 というのが計画だった。当時、このソフトウェアが新しかったのは、 ソフトウェア自身を我々のサーバーで走らせて、 通常のWebページをインタフェースにするという点だった。

もちろんたくさんの人達がこのアイディアを思い付いていたのだろうが、 私の知る限り、Viawebは最初のWebベースアプリケーションだった。 そのアイディアがとても斬新なものに思えたので、私達は自分の会社を そのように名付けたくらいだ:私達のソフトウェアはユーザのデスクトップでは なく、webを通して (via web) 動く、というわけだ。

もうひとつ、私達のソフトウェアがユニークだったのは、それが主にLispと呼ばれる プログラミング言語で書かれていたからだ [注1]。 それまで主として大学や研究所で使われていたLispの、事実上初めての大規模なエンドユーザ アプリケーションだった。 そして、パワーにおいて劣る他の言語を使っている競争相手に対して、 Lispは強力なアドバンテージとなった。

秘密兵器

エリック・レイモンドはエッセイ 「ハッカーになろう」の中で、 他のいろいろなアドバイスに混じって、ハッカーになりたい人はどんな言語を 勉強すべきかを述べている。まずPythonとJavaから始めよ、学ぶのが容易だから。 真剣なハッカーはさらに、UnixをハックするためにCを学び、システム管理と CGIスクリプトのためにPerlを学ぶべし。そして本当に真剣なハッカーはLispを 学ぶことを熟慮すべきだ。というのも:

LISPは、それをものにしたときのすばらしい悟り体験のために勉強しましょう。 この体験は、その後の人生でよりよいプログラマーとなる手助けとなるはずです。 たとえ、実際にはLISPそのものをあまり使わなくても。

これはまるでラテン語の勉強について語っているみたいじゃないか。 ラテン語を勉強しても就職には役に立たない(まあ、古典の教授を除いては)。 でもそれはあなたの心を豊かにし、英語なり何なりの実際に使う言葉をよりうまく 使えるようになる。

でもちょっと待った。このメタファーをそこまで敷衍していいのか。 ラテン語を勉強しても職が無いのは誰もそれを話さないからだ。 ラテン語で何か書いたって、誰も読んじゃくれない。でもLispはコンピュータ言語だ。 コンピューターは、何であろうとプログラマが選んだ言語を話すんじゃないか。

だとしたら、もしエリックが言うようにLispが良いプログラマーを作るなら、 Lispを使ってみちゃあどうか。画家が、これを使えば腕が上がるという筆を手にしたら、 自分の描く絵でそれを使ってみたいだろうと私は思うんだ。 別に私はここでエリックの挙げ足を取っているわけじゃない。全体として、 彼のアドバイスはとても良い。彼がLispについて言っていることはよくある意見だ。つまり、 Lispを学べばよいプログラマーになれる、でもそれを実際に使うことはない、と。

何故だい? プログラミング言語なんてただの道具じゃないか。Lispで良いプログラムが 書けるなら、使うべきなんだ。そうでないならいったい何の役に立つ?

これはただの机上の空論じゃない。ソフトウェアビジネスは極めて競争の激しい業界で、 結果的に自然な独占を許す傾向にある。ある会社が他の会社より、他が同じ条件で、 ただより良いソフトウェアをより早く書いたとしたら、他の会社はいずれ潰れる。 ベンチャー企業では特にそうだ。ベンチャーは、オール・オア・ナッシングの勝負になりがちだ。 大金持ちになるか、何も手に入らないか。ベンチャー企業では、もし間違った技術に 賭けてしまったら、いずれ競争相手に潰されるだろう。

ロバートと私はともによくLispを知っていて、私達の直観を覆すようないかなる 理由も見当たらなかった。他の誰もがC++やPerlを使っていることは知っていた。 でもそれは私達には何の意味もないことだった。もし、他の誰もが使っているからと いう理由で技術を選ぶなら、Windowsを走らせておけばいいのさ。 技術を選択する時は、他の人がどうやっているかなんて無視して、 何が最適かを見極めることだけを考えるべきだ。

特にベンチャー企業ではそうだ。大企業では、他の大企業がやっているのと 同じようなことをしていても良い。ベンチャーは他のベンチャーと同じことを やっていてはいけない。このことに、ベンチャー企業の中に居てさえ 気付いていない人が多いんじゃないかと思う。

平均的な大企業は年に10%成長する。だから、あなたが大企業を経営していて、 他の大企業がやっているのと全く同じようにやっていれば、 やはり年に10%くらいの成長が期待できるだろう。

もちろん、同じ論理はベンチャー企業にも成り立つ。 もしあなたが平均的なベンチャー企業と同じことをやっていれば、 平均的な成長率が期待できる。問題は、だ。ベンチャー企業の平均的な成長とは、 すなわち、潰れてしまうということだ。ベンチャー企業の生存率は50%よりはるかに 小さい。したがって、ベンチャーをやるなら何か変わったことをしなければならない。 そうでなければ、困ったことになる。

1995年当時、私達は、多分競争相手は理解してないであろうあることを知っていた。 いや、今でも理解している人はほとんどいないかもしれない。 もしあなたが、あなたのサーバー上でだけ走るソフトウェアを書くのなら、 あなたは自分の好むどんな言語でも使えるということだ。 デスクトップソフトを書いている時にはこうはいかない。そのデスクトップの オペレーティングシステムがサポートする言語への強いバイアスがある。 10年前なら、アプリケーションを書くということはCで書くということだった。 でもWebベースのソフトウェアなら、そして特に言語とOSのソースコードを 持っているなら、あなたは好きな言語を使うことができる。

この新しい自由は、しかし、両刃の剣でもある。どんな言語でも使えるということは、 どれを使うかを考えなくちゃならないということだ。あなたが その違いに気付かないふりをしていたら、競争相手に差を付けられてしまうかもしれない。

もしどんな言語でも使えるとなったら、いったい何を使う? 私達はLispを選んだ。 一つには、このマーケットでは素早く開発することが重要だというのが明らかだったからだ。 私達も競争相手もゼロから始めるところで、だから競争相手より少しでも速く新しい機能を 実現できればそれは大きなリードになった。Lispはソフトウェアを素早く書くのに 良い言語だ。そしてサーバーベースのアプリケーションはその利点を増幅する。 完成したらすぐにリリースできるからだ。

他の会社がLispを使いたがらなければ、それは良いニュースだ。 それは私達にとって技術的に有利な点になり得たし、 スタートしたばかりのベンチャー企業としては何であれ有利な材料は必要だった。 Viawebを始めたとき、私達にはビジネスの経験が無かった。マーケティングのことも、 人を雇うことも、資金を集めることも、顧客を得ることも、何一つ知らなかった。 そして私達のどちらも、あなたが「現実の仕事」と呼ぶものに就いたことさえなかった。 たった一つ、私達が良くできたのはソフトウェアを書くことだった。 私達はそれに賭けた。ソフトウェア部門に有利になることなら何だって採り入れようとした。

これを聞いたら、Lispを使ったことは実験だったって思うかもしれないね。 私達の仮説は、Lispでソフトウェアを書けば、競争相手より速く機能を実装することができて、 また競合ソフトウェアが出来ないことが出来るようになるだろうというものだった。 そしてLispは非常に高機能なため、大きな開発チームは必要無くて、開発費用も押さえられるだろう。 そうなればより安く、より良い製品を提供することができて、利益を上げられるだろう。 全てのユーザーをこっちに引き付け、競争相手を蹴散らせるだろう。 とにかくこれが私達が目論んだことだった。

実験の結果はどうだったかって? 実際驚くことに、うまく行ったんだ。 結果的に私達には20から30にものぼる競争相手が現われたが、どれひとつとして 私達のソフトウェアを打ち負かすことはできなかった。 私達のWYSIWYGのオンラインストアビルダーはサーバー側で走っているのに、 ユーザーからはまるでデスクトップアプリケーションを使っているかのように感じられた。 競争相手はCGIスクリプトを使っていた。そして機能的にも、 私達は相手のはるか先を行っていた。しばしば、競争相手は追い詰められて、 私達のソフトに無い機能を入れようと試みた。しかし、Lispのおかげで 私達の開発サイクルは非常に速く、相手がプレスリリースを出した1日2日後に もう同様の機能を作ったこともしばしばある。プレスリリースをカバーした記者が 私達のところに取材に来る頃には、こちらにももう新しい機能が追加されていたのだ。

きっと競争相手には、私達が何か秘密兵器を持っているかのように見えたに違いない。 彼等の暗号通信を解読しているとか、そんなことだ。事実、私達は秘密兵器を持っていたんだが、 それは彼等が思っているよりずっと簡単なことだった。誰も彼等の計画を私達に漏らしたりしなかった。 単に、私達が他の誰よりも素早くソフトウェアを開発できたというだけのことだ。

9歳くらいの時、私はフレデリック・フォーサイスの『ジャッカルの日』を読んだ。 主人公はフランスの大統領を殺すために雇われた暗殺者だ。 彼は大統領の通る道を見下ろすアパートに登るために警官の警備網を 抜けなければならなかったのだが、松葉杖をついた老人の格好をするだけで、 やすやすと警官の前を疑われずに通り抜けたのだ。

私達の秘密兵器も同じようなものだ。私達はソフトウェアを、括弧だらけの 奇怪な構文を持つ、妙ちきりんな人工知能言語で書いた。正直なところ 何年もの間、私はLispがそんなふうに呼ばれることが気にさわっていたのだが、 今やそれは私達のアドバンテージとなったのだ。ビジネスでは、競争相手が理解出来ない 技術的アドバンテージを持っていることほど価値あることは無い。ビジネスでは、 驚きは軍隊ほどに価値がある。

そして、ちょっと恥をしのんで告白すると、私達がViawebを作っている間、 私はLispについて一切公言しなかった。プレス発表でも言わなかったし、 私達のWebサイトで "Lisp" を検索しても見つかるのは私の書いたLispに関する 2冊の書物のタイトルだけだ。これは偶然そうなったわけじゃない。 ベンチャー企業はライバルになるべく情報を漏らさないものだ。 もしライバルが、私達のソフトが何で書かれているか知らないのなら、 あるいは気にしないのなら、私はそれをそのままにしておきたかった [注2]

私達の技術を一番理解していたのは私達の顧客だった。 お客さんはViawebが何の言語で書かれているかなんて気にしないが、 ソフトがとにかく使えるということに気付いてくれた。 私達のソフトを使えば、見栄えがいいオンラインストアを文字通り数分のうちに 作ることができた。そしてほとんど口コミによって私達は顧客を獲得していった。 1996年の終りまでに、70店程がオンラインストアを実現した。1997年の終りには500店 になった。その6ヵ月後、Yahooが私達の会社を買い取った時、顧客数は1070店になっていた。 こんにち、私達のソフトウェアはYahoo Storeとしてこの領域のマーケットを独占している。 それはYahooの中で最も利益を上げている部分の一つであり、それによって作られたオンラインストアが Yahoo Shoppingの基礎となっている。私は1999年にYahooを離れたので、 現在どのくらいのユーザーがいるのかは知らないが、最後に聞いた時はだいたい14000ということだった。

時々、Yahoo Storeは今でもLispを使っているのかと聞かれる。 答えはイエスだ。Lispコードはそっくりそのまま、まだある。 Yahooはサーバー側のソフトウェアを、 エリック・レイモンドが薦めた5つの言語全てを使って書いている。

「ほげ言語」のパラドックス

Lispの何がそんなに素晴らしいんだ? それに、もしLispがそんなに良いのなら、 どうしてみんなそれを使わないんだ? これは修辞疑問みたいに聞こえるが、きちんとした答えのある質問だ。 Lispは、信者のみが見ることができる魔法の特性があるから素晴らしいんじゃない。 単に、今ある言語の中でもっともパワフルだからだ。 そして、みんながそれを使わない理由は、プログラミング言語とは単なる技術だけでなく、 心の習慣でもあり、それは最も変化の遅いものであるというものだ。 もちろん、この二つの答えはもっとよく説明されなければなるまい。

まず、思いっきり物議を醸しそうな発言から始めよう。 プログラミング言語は、その力において差がある。

少なくとも、高級言語は機械語より力があるということに反対する人はほとんど居ないだろう。 こんにちではほとんどのプログラマーは、通常、機械語でプログラムを書きたいとは思わない ということに同意するだろう。かわりに高級言語で書いて、 コンパイラにそれを機械語に変換させるべきなのだ。 この考えは既にハードウェアの設計に採り入れられている。 1980年代以降、命令セットは人間のプログラマよりはコンパイラ向けに設計されるようになった。

あなたがプログラムの全てを機械語で書くと言い出したら、誰もがそれは間違いだと言うだろう。 しかし、同じ原理だが見過ごされがちな一般法則がある。もしあなたがいくつかの言語を 選択することができて、他の条件が同じ場合、最も力のある言語以外を選択することは間違いなのだ [注3]

この法則には例外がたくさんある。例えばあなたの書くプログラムが、別の、特定の 言語で書かれたプログラムと緊密に動作しなければならないとしたら、多分同じ言語で プログラムを書くのが良い方策だろう。もしあなたのプログラムが非常に簡単なこと、 たくさんの計算をこなしたりビット列を処理したりするなら、あまり抽象度の高い 言語で無いほうがいい。抽象度の低い言語の方がそういう動作が速いからだ。 そしてもしあなたが、小さい、一度使ったら捨ててしまうようなプログラムを 書いているなら、その目的に一番あったライブラリを持っている言語を使うのが 良いだろう。でも一般的には、アプリケーションを書くなら、手に入るなかで 最も力の強い(そしてそれなりに効率の良い)言語を使うべきだし、そうでない選択は、 程度の差こそあれそこで機械語を使うことが間違いであるのと同様の理由で、間違いなのだ。

機械語は非常に低レベルだということは誰にでもわかる。しかし、少なくとも 社会的な慣習として、高級言語は対等であるとされることが多い。 そんなわけはない。「高級言語」なんて用語は何も定義しない。 一方に機械語を、もう一方に他の全ての高級言語を隔てる線なんてありはしない。 プログラミング言語はそれぞれが、機械語から最も力のある言語までの 連続した抽象度のスペクトルのどこかに位置するのだ [注4]

Cobolを考えてみたまえ。Cobolは、それがコンパイルされて機械語に落とされるという 点では高級言語だ。しかし、Cobolが例えばPythonと同じ力を持つ、と真剣に主張したい 人はいるかい? 多分CobolはPythonよりは機械語に近い。

じゃあPerl 4はどうだろう。 Perl 4からPerl 5になる時に、レキシカルクロージャが追加された。 多くのPerlハッカーは、Perl 5はPerl 4よりパワフルだということに 同意するだろう。しかしそれを認めるということは、高級言語の間に力の差がある ということを認めるってことになる。そしてそれを認めるってことは、 特別な場合を除いては、最もパワフルな言語を使うべきってことになる。

でも、この考えが結論のところまで辿られることは滅多にない。 ある年齢に達すると、プログラマーは自分から使う言語を変えることは ほとんどなくなる。何の言語を使っていようと、これで十分だと 思ってしまうのだ。

プログラマは自分の好みの言語を深く愛する質だし、私は誰も傷つけたくないので、 ここで仮想的なプログラミング言語「ほげ」を使って私のポイントを説明しよう。 「ほげ」は抽象度のスペクトルのちょうど真中に位置するものとする。 最もパワフルな言語ではないけれど、Cobolや機械語よりはパワフルだ。

そして、仮想的な「ほげ」プログラマ氏は、Cobolも機械語も使わない。 もちろん機械語なんて使わない。あれはコンパイラのためのもんだ。 それにCobolだって、あれで何かをきちんと動かしたことがあるって人を知らないよ。 結局のところ、「ほげ」にある機能xが無いもんな。

このプログラマ氏がパワーのスペクトルを見下ろしている時、 彼にはそうしているという自覚がある。「ほげ」よりも力の弱い言語は、 明らかに力が弱い。彼が慣れ親しんだ機能が無いからだ。 しかし、このプログラマ氏が反対の方向に目を転じた時、彼は自分が見上げているのだということに 気付かないのだ。彼が目にするのは、変てこりんな言語ばかり。 多分、それらは「ほげ」と同じくらいパワフルなんだろうけど、 どういうわけかふわふわしたおまけがいろいろついているんだ、と思うだろう。 彼にとっては「ほげ」で十分なのだ。何故なら彼は「ほげ」で考えているから。

でも、これよりもう一段階パワフルな言語を使っているプログラマを考えてみると、 多分彼は「ほげ」を見下ろす位置にいる。いったい「ほげ」で何ができるっていうんだい。 あれには機能yさえ無いじゃないか。

帰納的に、全てのプログラミング言語の力の違いを見分けることが出来るのは、 最もパワフルな言語を理解するプログラマのみであるということになる (これが、エリックがLispは良いプログラマを作ると言った真意だろうと思う)。 この「ほげ」のパラドックスのために、他の人の意見は参考にならない。 誰であれ、プログラムについて考える時には 自分が使うことになった言語に思考が支配されているから、その言語に満足してしまうんだ。

私は自分の経験からこのことを知った。高校生の時私はBasicでプログラムを書いていたんだ。 再帰も無い言語でだ。再帰無しでプログラムを書くなんて今じゃ考えられないけれど、 当時は何とも思わなかった。全てをBasicで考えていたからだ。 そして私はBasicの達人だった。知る限り全てのことをマスターしていた。

エリックがハッカーに薦めた5つの言語は、パワースペクトルの違った場所にそれぞれ位置する。 どれがどこに来るかは微妙な問題だけれど、私は、Lispは一番上に来ると言おう。 そしてこの主張を裏付けるために、他の4つの言語に欠けているある一つの機能を 言おう。いったいこの機能z無しでどうやってプログラムを書くんだい? っていう、 そのzの最も大きなものの一つとして私が考えるのが、マクロだ ([注5])。

たくさんの言語が、マクロと呼ばれる機能を持っている。でもLispのマクロは特別だ。 そして、信じられないかもしれないけれど、それが強力なのはLispのあのたくさんの括弧と 深い関係がある。Lispは別に他と違いを出すために括弧だらけになったんじゃない。 「ほげ」プログラマにしたら、Lispの括弧は変てこりんにしか見えないだろうけど、 あれにはちゃんと理由があるんだ。そしてそれが、Lispと他の言語との根本的な違いの証拠なんだ。

LispのプログラムコードはLispのデータオブジェクトから出来ている。 それは、ソースコードは文字列で出来ていて、文字列は言語でサポートされている、 というようなつまらない意味じゃない。Lispのコードは、ひとたびパーザによって読まれたら、 あなたが解析することができるデータ構造になるんだ。 コンパイラの動作を理解していれば、Lispの構文は奇妙だと言っても Lispには構文が無いと言ってもたいした違いは無いということがわかるだろう。 他の言語ならコンパイラが構文解析して内部に作られる構文木を、 Lispでは直接プログラムとして書き下すわけだ。 しかも、この構文木はプログラムからアクセスできるから、 構文木自身を操作するプログラムを書くことができる。 Lispではそのようなプログラムをマクロと呼ぶ。いわば、プログラムを生成するプログラムだ。

プログラムを生成するプログラムだって? いつそんなものが必要なんだ? そんなこと滅多にないよ、とCobolプログラマは言うだろう。 いつでもさ、とLispプログラマは言うだろう。 ここでパワフルなマクロの例をここで見せて、ほらどうだい、と言えればいいんだろうけれど、 そうしたところできっとLispを知らない人にはわけのわからないデタラメ語にしか見えないだろう。 その例が何を意味するかを説明しているだけのスペースはここにはない。 ANSI Common Lisp を書いた時、私はなるべく素早くいろいろなことを 詰め込もうとしたのだけれど、それでもマクロは160ページになるまで出せなかった。

でも別の数字を使って多少説得力のある議論は出来るかもしれない。 Viawebエディタのソースコードのうち20-25%はマクロだ。 マクロは通常のLisp関数より書くのが大変だし、必要の無いところで使うのは 良くないスタイルとされている。だから、このプログラムコードにあるマクロはすべて 必要があって書かれたんだ。つまり、このプログラムの、少なくとも20-25%の部分は、 他の言語では簡単にできないような真似をやってのけているってことだ。 「ほげ」プログラマが私の主張するLispの神秘的な力にどんなに懐疑的であっても、 この事実にはちょっと好奇心をくすぐられるんじゃないか。 別に私達は自分の楽しみのためにこれらのコードを書いていたんじゃない。 私達は小さなベンチャーで、私達とライバルとの間の技術的な差を広げるために 可能な限りがりがりとコーディングしていたんだ。

勘の良い人は、ここに何かの関係があるんじゃないかと思い始めるだろう。 私達のコードの大きな部分は、他の言語を使ったらものすごく難しいようなことをやっていた。 出来上がったソフトウェアは、ライバルのソフトウェアには出来ないようなことが出来た。 恐らくこれには関係があるんだ。このことを深く考えてみてほしい。 あの老人が杖をついていたということには、目に見えること以上に深い意味があるんだ。

ベンチャーのための合気道

でも私は、(25歳過ぎの)誰かの心を変えて今からLispを勉強させることができるとは 思っていない。この記事の目的は人の心を変えようということじゃなく、 既にLispに興味を持っている人の後押しをしようということなんだ。 Lispはパワフルな言語だとは知っているけど、あんまり使われていないから不安だなあという人達だ。 でも競争の激しい状況では、そのことは有利になるんだ。 Lispの力は、ライバルがそれを理解できないということによって増幅されるんだ。

もしあなたがベンチャーを立ち上げようとしていて、Lispを使おうかと考えているなら、 他で使われていないからなんて心配してちゃいけない。今後も他で使われないことを期待しなきゃ。 そして多分その期待は正しい。今使っているプログラミング言語で満足してしまうっていうのが プログラミング言語に元来備わった性質なんだから。コンピュータのハードウェアは人間の習慣よりも 遥かに速く変化するから、プログラミングスタイルはプロセッサより10年から20年は遅れている。 MITのような場所では1960年代の始めから高級言語が使われていたけれど、 多くの企業では1980年代も半ばになるまで機械語でのコーディングがまかり通っていた。 多分、たくさんのプログラマは、プロセッサがRISCインストラクションセットに切り替えて、 店仕舞いして早く家に帰りたいバーテンダーに追い出されるようにして とうとう機械語でのプログラミングから追い出されることになるまで、 機械語でコードを書き続けていたんじゃないかと思うよ。

普通の技術は速く変化する。でもプログラミング言語はちょっと違う。 プログラミング言語は単なる技術ではなく、プログラマーがそれを道具として思考するものだからだ。 プログラミング言語は半分技術で、半分は宗教なんだ [注6]。 だから中くらいのプログラミング言語、つまり普通のプログラマが使うような言語ということだが、 それはまるで氷山の動きのようにゆっくりと変化する。 1960年頃にLispによって導入されたガベージコレクションは、 近年では良い技術だと広く認められるようになった。 実行時型判定も同じくポピュラーになりつつある。 レキシカルクロージャは1970年代はじめにLispによって導入されたが、 ようやくレーダーの端に捉えられはじめた。1960年代中頃にLispが導入したマクロは、 まだ未知の世界だ。

もちろん、普通の言語は恐るべきモーメントを持っている。 この力と闘えなんて言うつもりはない。むしろ私が言いたいのは全く逆のことなんだ。 つまり、合気道家がやるように、相手の力を相手を倒すのに利用するんだ。 あなたが大企業で働いているならこれはちょっと難しいかもしれない。 つい今しがた、ある言語が世界を支配するみたいな記事(20年前のAdaがそうだった)を 読んだばかりの、髪のとんがった上司(訳注)を説得して、 Lispで何かを作らせてもらうのはかなり厄介だ。 でもあなたが、まだ髪のとんがった上司なんかいないベンチャーで働いているなら、 私達がやったように、「ほげ」のパラドックスを自分に有利なように利用できる。 競争相手が普通の言語に貼り付いて動けないでいるうちに、彼等が決して対抗できない 技術を使えるのだ。

もしあなたがベンチャーで働いているなら、競争相手の実力を見積もる便利なヒントをあげよう。 人材募集内容を見るんだ。彼等のウェブには他に見栄えのいい写真や美辞麗句で彩られているだろうけど、 募集内容だけは彼等が一番欲しているものを的確に表現しているはずだ。 でなければ見当違いの人しか応募して来ないからね。

Viawebで働いていた期間、私は人材募集記事をたくさん見た。 新しい競争相手は毎月のように現われた。いつも最初に私がしたことは、 まずオンラインデモがあるかどうかをチェックして、それから人材募集を見ることだった。 1〜2年したら、警戒すべきライバルとそうでないところとを見分けられるようになった。 人材募集がいかにもITといった匂いをただよわせていればいるほど、その企業は脅威ではない。 一番安全なのはOracleの経験者を募集しているところだ。 そういうところを警戒する必要は全く無い。 また、JavaやC++プログラマを募集しているところも安全だ。もしPerlやPythonプログラマを 募集していたら、ちょっと気を付けたほうがいい。その企業の、少なくとも技術部門は 本物のハッカーがやっている可能性が高いからだ。 もし私がLispハッカーの募集広告を目にしていたら、きっとかなり心配していただろう。

Lispの本を書いていた時、私は皆がLispを分かってくれたらいいと願っていたものだ。 Viawebを立ち上げた時、私の見方は変わった。Lispを分かって欲しい。 但し競争相手以外に、だ。


原注:

  1. 注1: 当初、Viawebは二つの部分から構成されていた: Lispで書かれた、ユーザーがサイトを構築するエディタと、Cで書かれた注文を処理するシステムだ。 最初のバージョンでは注文処理システムは小さかったので、ほとんどの部分がLispだった。 後に私達はモジュールをもう二つ---Cで書かれた画像生成システムと、ほぼPerlで書かれた バックオフィスマネージャを---追加した。
  2. 注2: ロバート・モリスは、そんなに秘密にする必要は 無いんじゃないかと言った。もし私達がLispを使っていることをライバルが知っても、 その理由を理解することはできないだろうと。「だってそれが理解できるくらいなら、 もうLispでプログラムしているはずだよ」
  3. 注3: 全ての言語はチューリング等価であるという意味で同等の力を持つけれど、 プログラマーが言語の「力」というのはそういう意味じゃない (誰もチューリングマシンで プログラムを書きたいとは思わないよね)。プログラマーが気にする「力」とは、 明確に定義できるものではないけれど、たとえば、 ある機能を実現するのに、力の弱い言語では、その機能を含むようなより力の強い言語の インタプリタを書くことでしか実現できない、というふうに言える。 例えば言語Aが文字列からスペースを除くオペレータを持っていて、言語Bがそれを 持っていなかったとしよう。これだけで言語Aは言語Bより力が強いとは言わないだろう。 多分言語Bで同等のことをするサブルーチンが書けるからだ。 けれど、例えばAは再帰呼び出しをサポートしていてBはそうでないとしたら。 ちょっとしたライブラリ呼び出しでBをAに近づけるのは簡単じゃない。
  4. 注4: こだわる人への注:あるいは、頂上に近付く程 細くなっている束(そく)と言っても良いかもしれない。ここで問題にしているのは 形状ではなく、少なくともそこには半順序があるということだ。
  5. 注5: マクロを一つの独立した機能と言ってしまうのは ちょっと誤解を招くかもしれない。マクロの有用性は、レキシカルクロージャや rest引数 というような他のLispの機能と組み合わせて生まれてくるものだからだ。
  6. 注6: 結果として、プログラミング言語の 比較は宗教戦争になるか、中立であろうとするあまりに 人類学の研究かと見まごうような学部生用の教科書にしかならない。 平和を好むか、大学での終身雇用を手に入れたい人は、この話題を避けて通る。 でも、宗教的な部分はこの問題の半分だけなんだ。他の部分には研究すべき価値がある。 特にあなたが新しい言語を設計したいと思っている時には。

訳注:

  1. (11/20/2001追加): 髪のとんがった上司(pointy-haired boss): Dilbertに出て来るキャラクタ→ こんなの。"pointy-haired" は文字通りとれば髪の毛がつんつんと立っていることで、 最初はそう訳していたんだけど、 freshmeatの記事 を読んで気付いたのだった。

訳者あとがき:

この記事を知ったのは、SlashDotに 取り上げられていたのを同僚が見つけて「気に入るんじゃない?」と教えてくれたメイルからだった。 一読してあまりに面白かったので、勢いでその日のうちに訳してしまった。

「使う人が少ないから有利なんだ」という逆説には、 マイナー言語使用者の自虐的な哀愁が漂っている気がしないでもないが、 私が見事だと思ったのはプログラミング言語の「力」とそれに対するプログラマの認識を 分析してみせるくだりである。

Lispが本当に一番上に来るかどうかってところには異論のある人もいるだろう (slashdotでは案の定というか、大論争を巻き起こした)。 だが、言語を比較するには両方の言語について深く理解していなければならないということ、 自分の知らない言語については、たとえそれが機能的に上位であっても それを理解できないであろうということに関しては、複数の言語を使いこなす プログラマなら誰もが同意するところではないだろうか。

それにしても、 プログラミング言語について語るとき、原注3で説明されるようなライブラリレベルの 機能と言語レベルの機能を混同している例のなんと多いことか。 例えばVisual Basicのマニュアルや多くのガイド本。VBにだって使い所はあると思うけど、 最初にそういった本でプログラミングを勉強してしまったプログラマは、 プログラミング言語の本質的な構造というものに、ともすれば触れずに終わってしまうんではないか。 それはまるで地図もコンパスも持たずに森に入るようなものだ。 本人はがんばって進んでいるつもりでも、同じところをぐるぐる回っていたり、 まるで見当違いの方向に進んでみたり… そうなったら本人にとっても周囲にとっても不幸なことである。


[Practical Scheme]