これは、Paul Graham：Re: Revenge of the Nerds を、原著者の許可を得て翻訳・公開するものです。
プロジェクト杉田玄白正式参加テキスト。
<版権表示>
本和訳テキストの複製、変更、再配布は、この版権表示を残す限り、自由に行って結構です。
(「この版権表示」には上の文も含まれます。すなわち、再配布を禁止してはいけません)。
Copyright 2002 by Paul Graham
原文: http://www.paulgraham.com/icadmore.html
日本語訳：Shiro Kawai (shiro ＠ acm.org)
<版権表示終り>
Paul Graham氏のエッセイをまとめた『ハッカーと画家』の
邦訳版が出版されました。
出版社の案内ページ
Amazon.co.jp
サポートページ
2002/06/02 翻訳公開
2002/06/10 プロジェクト杉田玄白正式参加に伴い版権表示を整備
2002/10/15 Peter Norvigの"Python for Lisp Programmers"の日本語訳をリンク
「技術野郎の復讐---Revenge of the Nerds---」は 多くの議論を巻き起こした。当記事で取り上げた問題に関してより深く考えたい方々の ために、その議論をここにまとめておく。
Trevor Blackwellは、Lispが優るのはある種のクラスの プロジェクトだけではないかと書いた。彼のメイルは非常に明快なので、 ここにそのまま掲げておく。
Lispがどのような場面で優るかということを限定したほうが、 議論に説得力がつくように思えます。 Lispは例えば以下のような目的では他の言語より優れてはいないでしょう：
- 通信、インタフェース、フォーマット変換
- リアルタイム制御
- 数値計算中心のコード
- オペレーティングシステム実装
- ファイルを読み書きするようなちょっとしたスクリプト
上に挙げたものは、実際には書かれるソフトウェアの非常に多くの部分を占めています。
Lispは情報処理、すなわち非常に複雑なアルゴリズムを 非常に複雑なデータセット上に適用するような場合には優れているでしょう。 ごく最近、WWW時代になって、 ようやくそのようなプログラムが広く書かれるようになって来ました。
Webが広まる以前は、複雑なアルゴリズムを含んでいるソフトウェアは 極めて少数だったと思います。多くのソフトウェアでは、 最も複雑な部分といえばソートアルゴリズム程度のものだったでしょう。 FreeBSDの中の複雑なアルゴリズムというのを思い付きますか? Nortelのスイッチの5000万行のコード中には、多分ソートさえ無かったでしょう。 全てのコードはハードウェアとリソースを管理し、エラーを順当に処理するための ものでした。Ciscoのルータにも数100万行のコードがありますが、 複雑なアルゴリズムはそれほど入っていないと思います。
ITAが書いたようなソフトウェアは非常に稀です。 10年前には、本当に複雑なアルゴリズムを必要とした唯一のソフトウェア分野は CAD設計と合成でした。それらは実際、Lispを使って書かれていました。
書かれるソフトウェアの種類が変わって来たからこそLispが 再び素晴らしい選択として現れたのだ、と言うほうが、 大部分のプログラマは40年間、ずっと間抜けだったと言うよりもはるかに 信じやすい説になるでしょう。
確かに、低レベルのプログラム、ビット列を動かしたり、 プログラマの費す時間よりも実行時間を短くするほうがはるかに大事な場合などには、 Lispは良い言語ではない、ということには私も同意する。 そういうものには、Cやアセンブリ言語が必要だろう。 しかし、そのようなアプリケーションはごく少ないし、(Mooreの法則により) 今後ますます少なくなると思われる。Rod BrooksのロボットR&Dラボ等、 Lispをリアルタイムアプリケーションに使っているいくつかの場所を私は知っている。
また、Cで書かれたプログラムと緊密に動作するコードを書くのに Lispは理想的な言語ではないだろう、ということにも私は同意する。 でもそれはLispのせいではない。Lispで書かれたプログラムと緊密に動作するコードを 書くのにCは理想的ではない、とも言えるからだ。
Lispがちょっとしたスクリプトを書くのに適していないという点には同意しかねる。 Lispのインタラクティブ性はむしろそのような目的に適している。
また、40年もの間、大多数のプログラマは間抜けだったのは信じ難いという点にも 同意しかねる。私にしてみれは、それは実にありそうなことだ。 ほとんどいかなる分野においても、 ユーザーの数で比較した場合の先頭を行く技術は中庸だ。Windowsを見たまえ。
技術的な発展が広がるのには何十年もかかる。 フォルクスワーゲンは1930年代からユニボディ構造の車を生産してきた。 1980年代までに、ほとんど全ての新しい車はそのように設計されるようになった。 これは単に、大多数の車の設計者は40年間、間抜けだったってことかい? そうだ。ただ、「保守的」という婉曲な言い回しの方が好まれるだろうが。
Bengt RichterはPythonでの別の解法を作成した。だが、Pythonハッカーはやはり新しいクラスを作る方が一般的なやり方だと考えるんじゃないかと思う。
何人かのPythonユーザは、Lisp/Perl/Smalltalk/Javascriptの例のプログラムが Pythonで書けないのは、Pythonのレキシカル変数は変更不可であり、 無名関数は一つの式しか含むことができないからだ、と書いてきた。 私が、なぜPythonでは次のように書けないのか：
と言ったのは、別に現在のPythonの実装の何のせいでこれが出来ないのかを 尋ねていたわけではない。現在のPythonにそういう制限があることは知っている。 私が尋ねていたのは、そのような制限を設けることで何の得をするのかということだ。 外側のスコープの変数の値を変更できないとか、 lambdaの中に一つ以上の式を書けないとかいうことは、 言語としてのPythonをどんなふうにより良くしているんだ? 式と文を区別することで、いったいどんな得があるんだ?
特に、無名変数で出来ることの制限は、弁護のしようがないと思う。 そもそも「無名関数」と呼んだ時点で思考が制限されているんだ。 何かの変数の値になっていないハッシュテーブルを「無名のハッシュテーブル」なんて 呼ぶかい? もし関数がある言語のデータタイプだとしたら、 関数はその言語の他のデータタイプと同じように扱えてしかるべきだ。 名前のついた関数は、関数がたまたまある変数の値となっているってことだ。 変数の値となっていない関数で出来ることを制限するのは、 変数の値となっていないハッシュテーブルや文字列で出来ることを制限するのと 同じじゃないか。
Thomas Herchenroederは、言語はスーパーハッカーだけでなく、 普通のプログラマのためでもあるべきだということを強調した。
あなたは、他の素晴らしいハッカー達がそのコードを読んで精緻なアルゴリズムや コーディングスタイルを称賛するような、そんな卓越したハッカーのことを頭において いるのではないかと思います。彼らは新しいものを学ぶのが好きで、 知的な挑戦をして全てを理解することに純粋な喜びを覚える人々です。 残念ながら、私は(そして他のたくさんの人々も)そのような世界には住んでいません。 私の同僚は…最小限の努力で私のコードと付き合って行きたいのです。 したがって、言語の力とは平均的なITプロフェッショナルが簡単に咀嚼できるものと 関係することになります。すなわち、大学の授業で普通に教えられていて、 簡単に手に入る本に説明が乗っていて、 よく読まれる記事の中で取り上げられているようなものです。 それが結局、プログラミング、言語、アルゴリズムやパターンに関する主流の知識となります。 ある程度までは、多数派の人々に合わせなければなりません。 Pythonの話に戻れば、それは主流のコンセプトを簡潔でエレガントな方法で 実装しています。 話はこういう所に戻って来るかもしれません。 我々はパワーユーザ、ハッカー向けに「パワフルな」言語が必要である、 そしてまた、普通の会社で普通の人々が使う、(違う意味での)「パワフルな言語」が 必要であると。
初心者や、それほどプログラミングそのものには興味が無いプログラマ向けに 設計された言語にもその役割はあるということには同意する。 ただ、そこに「パワフルな」という語を使うのは違うと思う。 既に2番目の意味の「パワフル」に当たる単語はある。「アクセシブル」だ。 フェラーリはパワフルだ。フォルクスワーゲンのゴルフはアクセシブルだ。
既にその質を意味する単語があるのに、 わざわざ言葉の意味を拡張してまでゴルフを「パワフル」と呼べるようにする 必要があるだろうか。それに「パワフル」という言葉を広く曖昧に解釈しすぎると、 フェラーリが持つ確かな質に使う言葉が無くなってしまう。
少なくとも我々のうち何人かが フェラーリの意味での「力」に集中し続けることは重要だと思う。 誰かがそうしていなければ。それこそが次世代の「主流の知識」の源だからだ。 1980年には、大学の授業や簡単に手に入る本で 構造化プログラミングを説明しているものは、「進んでいる」とされていた。 現在、授業や本ではガベージコレクションや動的型付けについて説明されているが、 1980年にはそれらは秘密の奥儀のようなものだと考えられていたんだ。
Paul Prescodは、 私が選んだ例はわざとLispに有利になるようになっていると書いた。 もし私がそうしたかったのなら、私は関数でなくマクロを書いていただろう。 もし私の選んだ例が偏っているというなら、それは Lisp/Perl/Smalltalk/Javascriptに偏っているんだ。 この4つの言語のどれでも (そして他の言語でも)、 コードは同じように単純になる。
実際、Pythonでこんなにうまくいかないというのは驚きだった。 例えば、Pythonのlambda式の中に名前のついた関数と同じものを書けないとか、 外側のスコープ中の変数は見えるけれども変更できないといったことは今回初めて知ったのだ。 LispにもPerlにもSmalltalkにもJavascriptにも、そのような制限は無い。
これらの制限のおかげで何が得になっているのか、私にはわからない。 Pythonの段階的な(そしてまだ完成していない)進化がその制限を生み出したのであろう、 ということなら理解できる。 だからオッカムの剃刀を適用すれば、Pythonが今のようになっているのは 後者のせいなのだろう。すなわち、これらの制限はバグであり、機能ではないということだ。
Paulは「技術野郎の復讐」に対する反駁、 PythonとLispの関係についてを書いた。 (Peter Norvigもこのトピックに関して、 Python for Lisp Programmers (日本語訳 「LispプログラマのためのPython入門」)を書いている)。
「技術野郎の復讐」の付録で私が暗示した、 簡潔さがプログラミング言語の設計のために良いゴールなのかどうかについては、 LL1でたくさんの議論があった。この問いに関しては、別に 簡潔さは力なりで扱っている。