ポール・グレアム「言語の設計に関する5つの問題」を翻訳しました。




翻訳中にKumappus様、RC30-popo様、sibazyun様、andalusia様、


YasudaS様、SALINGER様の協力をいただいております。ありがとうございました。




また翻訳後の校正として、shiro様、korompa様、matsOS様、hujikojp様、


lethevert様、ttamo様、もがみ様の協力をいただいております。ありがとうございます。




原題は「Five Questions about Language Design」で、原文は以下です。


http://www.paulgraham.com/langdes.html






言語の設計に関する5つの問題


2001年5月




(これは2001年5月10日にMITで行ったプログラミング言語設計のパネル・ディスカッション用に書いたメモだ)




その1:基本原則




1. プログラミング言語は人間のためのものだ




プログラミング言語とは、人間がコンピュータに話しかける手段だ。コンピュータの方は、曖昧ささえ無ければどんな言語だって喜んで話すだろう。高水準言語があるのは、人間の方が機械語を操れないからだ。プログラミング言語の目的は、貧しく弱い私たち人間の脳が、多くのつまらないことに圧倒されないようにすることだ。


設計者は、ある種の設計は他よりも個々の人間に近い問題だと知っている。最もクリーンで最も抽象的な問題の1つに橋の設計がある。橋の設計では、最小の資材で与えられた距離をまたぐのが主な仕事になる。それと正反対の位置にいるのがイスの設計だ。イスのデザイナーは、人間のお尻について考えることに時間を費やす必要がある。


ソフトウェア問題も同様なバリエーションを持つ。ネットワークを流れるデータをルーティングするアルゴリズムの設計は、橋の設計と同様、高度に抽象的な問題だ。一方、プログラミング言語の設計はイスの設計と似ており、人間の弱点への対策がすべてとなる。


私たちの多くは、そのことを認めたがらない。人間の弱点への迎合と言うよりも、数学的に非常にエレガントなシステムの設計と言ったほうが多くの人にウケる。また数学的なエレガントさにも出番がある。ある種のエレガントさは、プログラムの理解を容易にするからだ。しかしエレガントさだけではダメだ。


プログラム言語は人の弱さに対応するように設計すべきだと私が言うとき、下手なプログラマのために設計しろと言っているのではない。実のところ私は、最高のプログラマのために設計するべきだと思う。だが最高のプログラマにさえ限界はある。変数はすべて整数の添え字つきの文字Xという言語では、誰もプログラミングをしたがらないだろう。


2. 自分自身と仲間のために設計せよ


プログラミング言語の歴史を振り返ると、最高の言語の多くは自分自身のために設計されていた。また、最低のものの多くは、自分以外の人が使うために設計された。


言語が他の人のために設計されるとき、それは常にある特定の集団、つまり言語設計者ほど賢くない人々を対象にする。その結果、人を見下した言語ができあがる。Cobolは最も極端な例だが、多くの言語がこの精神に汚染されている。


それは言語の抽象のレベルとは関係がない。C言語はかなり低水準だが、設計者が使うために設計された。だからハッカーはC言語が好きだ。


下手なプログラマ用の言語の設計を弁護する論拠は、「良いプログラマより下手なプログラマのほうが多い」というものである。それはそうだろう。でもその少数の良いプログラマが、不相応なくらい大きな割合でソフトウェアのプログラムを書く。


真に最高のハッカーが好む言語を、どうすれば設計できるだろう、という問題に私は興味を持っている。良いプログラミング言語をどう設計するか、という問題とも一致すると私は思う。そうでなくても、少なくとも面白い問題だ。


3. プログラマにできるだけ自由を与えよ




多くの言語(特に他の人のために設計された言語)は、住み込みの女性家庭教師のような態度だ。良くないと思うことは禁止するのだ。私はその反対の「プログラマにできるだけ多くの自由を与えろ」というアプローチが好きだ。


私がはじめてLispを学んだとき、いちばん気に入ったのは、Lispは私を対等のパートナーとみなすことだった。私がそれまでに学習していた他の言語では、言語があり、その言語で書いた私のプログラムがあり、そしてその2つは別物だった。でもLispでは、私が書いた関数とマクロは、言語そのものとよく似ていた。望めば言語自体すら書き直すことができた。それはオープンソースのソフトウェアと同じ魅力を持っていた。




4. 短く書けるようにしろ


簡潔さは過小評価され、拒否すらされる。でもハッカーの心理を調べれば、ハッカーは本当に簡潔さを愛しているとわかるだろう。そうだな、たとえばハッカーが「APLでは、コードを数行、書くだけですごいことができるんだ」とか愛情をこめて話すのを、何度、聞いたことだろう。本当に賢い人が本当に愛しているものには、すべて注意を払う価値があると私は思う。


私は、プログラムを短くすることに限ってはほとんど全てが、良いことだと思う。ライブラリ関数はたくさんあるべきだし、暗黙にできるならそうしたほうがいいし、文法は極端に簡潔であるべきで、さまざまな名前すら短いほうがよい。


また、単にプログラムさえ短ければよいのではない。マニュアルも同様、薄いべきだ。マニュアルの大部分は、説明、制約、警告、例外で占められている。マニュアルを短くすることを心がけると、うまくいけば多くの説明を必要とするような部分を修正することでマニュアルを短くすることすら起きるかもしれない。


5. ハックを認めろ


多くの人々はハックが数学か、せめて自然科学に似ていればと望む。私はハックはむしろ建築に似ていると思う。建築家は倒れないビルを設計する必要があるという点において、建築学と物理学には関係がある。しかし建築家の実際的な目的は素晴らしいビルを作ることであって、力学上の発見をすることではない。


ハッカーは凄いプログラムを作ることを好む。だから私たちは少なくとも心の中で「たとえ従来の研究の知的通貨に交換することがなかなか難しいとしても、凄いプログラムを書くことは賞賛に値する」と思う必要がある。論文として公表できるアイデアを具体化するひどい言語の設計に知的価値があるなら、プログラマが好む言語を設計することにも価値があるはずだ。


その2:未解決問題




1. 大きなライブラリを構成する方法


プログラミング言語においてライブラリはますます重要な要素になっている。またライブラリは大きくなっているが、これは危険を孕んでいる。ライブラリ関数を見つけるのに時間がかかると、プログラマは関数を自分で書くようになるだろう、そしてあなたの書いたコードは、マニュアルを厚くするだけで終わってしまう。だからライブラリを作る方法を考える必要がある。どのライブラリを呼び出だせばいいかプログラマが推測できるように設計するのが理想だろう。


2. みんなは本当に前置記法を怖れているのだろうか


私がそれについて何年も考えており、いまだに答えがわからないという意味で、これは未解決問題だ。おそらく数学を除けば、前置記法はまったく当然のことに私には思える。でもLispに人気がない理由の多くがなじみのない文法を持つから、ということはありそうだ。それが真実だとしても、それをどうにかすべきかどうかはまた別の問題だ




3. サーバ・ベースのソフトウェアには何が必要か




今後20年間に書かれる最も刺激的な新しいアプリケーションの多くは、サーバで走り、ブラウザがインターフェイスとなるという意味でウェブ・ベースのアプリケーションになるだろう。そうしてこういったタイプのプログラムを書くには、新しいものが必要になるかもしれない。


必要なものの1つは、サーバ・ベースのアプリケーションのリリースを支援する新しい方法だ。デスクトップ・ソフトウェアのように年間1つか2つの大きなリリースをするのではなく、サーバ・ベースのアプリケーションは小刻みな変化としてリリースされる。1日に5回から10回もリリースされるかもしれない。そして一般的に、みんなが常に最新バージョンを使うだろう。




どうすればデバッグしやすいプログラムを設計できるかはわかってるよね。うん、サーバ・ベースのソフトウェアは、さらに変更が容易であるように設計される必要がある。容易に変更可能か、せめて何が小さな変更で、何が重要な変更かを知ることができる必要がある。


それ以外でサーバ・ベースのソフトウェアで有用となる可能性があるのは、驚くなかれ、継続だ。Webベースのソフトウェアでは継続渡しスタイルのような形式を使うことで本来的にステートレスな世界であるWebセッションにサブルーチンと同じ効果を得ることができる。もしかすると、本物の継続を持つ価値さえあるかもしれない。それがあまり重くないならね。


4. まだ発見されていない抽象的な概念はあるだろうか?




どれくらい可能性があるのかわからないが、私が個人的にぜひしたいことの1つは新しい抽象的な概念の発見だ。ファーストクラスの関数、再帰、キーワードパラメータといった大きな特徴となるような。これは不可能な夢かもしれない。めったに見つかるものではないからだ。でも私はいつも探している。




その3:ほとんど知られていない秘訣




1. 好きな言語を使ってよい。




かつては「アプリケーションのプログラムを書く」ということと「デスクトップ用のソフトウェアを書く」ということは同じ意味だった。そしてデスクトップのソフトウェアでは、アプリケーションはOSと同じ言語で書いた方がずっと有利になる傾向がある。だから10年前は、ソフトウェアを書くとは、ほぼC言語でソフトウェアを書くことだった。そしてその慣習は発展し、アプリケーション・プログラムを人気のない言語で書いてはいけない、ということになってしまった。あまりに広まったため、経営者やベンチャー・キャピタリストといった専門外の人でさえそう思い込んでいるほどだ。


サーバ・ベースのソフトウェアはこのモデルをすべて吹き飛ばす。サーバ・ベースのソフトウェアでは、お望みのどんな言語を使っても良い。ほとんどの人は、このことをまだ理解していない(特に経営者とベンチャー・キャピタリストが理解していない)。少数のハッカーはそれを理解しており、それが私たちがPerlやPythonといったインディーズ言語を聞いたことがある理由だ。人々がWindowsアプリを書くのに使っているからPerlやPythonが有名になってるわけじゃない。


これは私たちプログラミング言語の設計に興味を持つ人々にとって「私たちの言語を待ち望んでいる人々がいる」ということを意味する。


2. スピードアップにはプロファイラが重要




言語の設計者は、少なくとも言語の実装者は、速いコードを生成するコンパイラを書くのを好む。でもこれはユーザにとって言語を速くするものではないと思う。クヌースははるか昔に、速度は少数のクリティカルなボトルネックでしか問題にならないと指摘した。またその経験のある人ならご存じの通り、ボトルネックがどこかの推定は困難だ。プロファイラがその答えとなる。


言語の設計者は見当違いの問題を解決しようとしている。ユーザはベンチマークが速く走ることなど求めていない。ユーザが求めているのはプログラムのどこを書き直す必要があるか教えてくれる言語だ。現実にはそれがスピードアップに結びつくからだ。だから言語の実装者は、コンパイラの最適化に費やす時間の半分を良いプロファイラを書くことに費やしたほうがトータルで見ると賢明だろう。




3. 言語の設計を方向づけるアプリケーションが必要だ




これは絶対の規則ではないかもしれないが、最高の言語は、その言語で書くことになっているアプリケーションと共に成長したように思える。C言語はシステム・プログラミングをしたいと思った人が作った。Lispは部分的には記号微分をするために開発されており、またマッカーシーは微分のプログラムを書くことにとても熱心で、1960年における最初のLispの論文で微分のプログラムを書いている。


そのアプリケーションが新しい問題を解決するなら最高だ。プログラマが必要とする新しい機能に言語を導くだろう。個人的にはサーバ・ベースのアプリケーションを書くのに適した言語の作成に興味がある。


[パネル・ディスカッション中に、ガイ・スティールも「自分の言語がたまたまコンパイラを書くための言語でもない限り、自分自身のコンパイラを目標にしてはいけない」と補足し、この点を主張した]




4. 言語は書き捨てのプログラムを書くのに適しているべきだ




書き捨てのプログラムとは、限定された仕事のためにさっと書くようなプログラムだ。調査をすれば、大きく重要なプログラムの多くは書き捨てのプログラムから始まったとわかるだろう。もしほとんどのプログラムが書き捨てのプログラムとして始まったとしても驚くにはあたらない。だから一般的なソフトウェアを書くのに適した言語を作るなら、それは書き捨てのプログラムを書くのにも適していなければならない。ほとんどのソフトウェアは書き捨てのプログラムから始まるからだ。


5. 文法が意味論と結びついている


従来、文法と意味論は完全に別だと考えられている。だからこのアイデアは衝撃的に思えるかもしれないが、実はそれほどでもない。どのような言語を作りたいかは、その言語で何を表現したいのかと関連すると私は思う。


私は最近、ロバート・モリスと話していたのだが、彼は「オペレータのオーバーロードは中置記法の言語でより役立つ」と指摘した。前置記法の言語では、どんなユーザ定義関数も実効的にはオペレータだ。あなたの考え出した新しい数のために、何かの追加を定義したければ、新しい関数を定義して付け加えるだけでよい。中置記法の言語でそれをするなら、オーバーロードのオペレータと関数呼び出しで使うときのプログラムでは、外観に大きな差があるだろう。


その4:昔のアイデアの復活




1. 新しいプログラミング言語




1970年代には、新しいプログラミング言語の設計が流行っていた。最近は流行っていない。だがサーバ・ベースのソフトウェアによって、再び新しい言語が流行になるだろう。サーバ・ベースのソフトウェアでは、望むどんな言語を使っても良い。したがって誰かが言語を設計し、実際に他の言語よりも良さそうに見えたなら、リスクを冒してでも使う人がいるだろう。


2. タイム・シェアリング




リチャード・ケルシーはパネル・ディスカッションで「時代が戻る」というアイデアを述べ、私は全面的に賛成する。私の推測では(おそらくマイクロソフトの推測でもあるが)、計算の多くはデスクトップではなくリモート・サーバ上で行われるようになるだろう。つまりタイム・シェアリングは復活する。また私は、タイム・シェアリングは言語のレベルでサポートする必要があると思う。たとえばリチャードとジョナサン・リースはScheme 48に多くのプロセス・スケジューリングを実装した。




3. 効率


最近、コンピュータはついに十分な速度を持つように見えはじめた。バイトコードについて聞くことが多くなり、少なくとも私には、サイクルに余裕があると示唆しているように思えた。でも私は、サーバ・ベースのソフトウェアに関してはそうではないと思う。誰かがソフトウェアが走るサーバの代価を払う必要が出てくるだろう。そして1台のマシンでサポートできるユーザ数は、必要なコストの分母になるだろう。


したがって、少なくとも計算力のボトルネックを考える上で、効率が問題となるだろう。サーバ・ベースのアプリケーションは多くの入出力を行うから、入出力を速くすることは特に重要だろう。


バイトコードは結局のところ勝者ではないとわかるかもしれない。Sunとマイクロソフトは、現在バイトコードで対決しているようだ。でもそれは、バイトコードを押さえることで主導権を握れるからであって、バイトコードが自体が良いアイデアだからではない。この戦場自体が無意味かもしれない。笑い話だね。


その5:落とし穴




1. クライアント


これは単に私の推測なのだが、ほとんどのアプリケーションにおいて、成功するモデルは純粋なサーバ・ベースのモデルだろう。すべての人が自分のクライアントソフトを導入すると仮定してソフトウェアを設計するのは、すべての人が正直だと想定した社会を設計するようなものだ。確かに便利なのだが、現実的ではない。


ウェブにアクセス可能なデバイスが急増するだろう。そして仮定していいのは簡単なhtmlとフォームのサポートだけだ。携帯にブラウザが実装されるだろうか?パーム・パイロットに電話が装備されるだろうか? ブラックベリーは大画面になるのか? ゲームボーイでウェブをブラウズできるか? 時計では? わからないけれど、全てがサーバ上に作られると考えればわからなくてもいい。サーバ上で全てが運用できれば、もっとずっと頑健なものになるのだ。


2. オブジェクト指向プログラミング




論争になるとわかってはいるが、オブジェクト指向プログラミングはそんなに大層なものではないと私は思う。ウィンドウ・システム、シミュレーション、CADのプログラムといった、ある種のデータ構造を必要とするアプリケーションには、オブジェクト指向プログラミングはすばらしいモデルだ。でもどうしてそれが、すべてのプログラミングのモデルになる必要があるの?


大企業の人がオブジェクト指向プログラミングを好む理由の一部は、仕事をしているように見える多くのものを生み出すからだと思う。たとえば整数型のリストなどで自然に表現できるようなものでも、オブジェクト指向プログラミングを使えば、いろいろな足場を積み重ねてわっせわっせと頑張った感じのクラスにすることができる。


オブジェクト指向プログラミングの別の魅力は、メソッドによってファーストクラスの関数の力の一部を与えられるということだ。だがこれはLispのプログラマにとって、新しくもなんともない。実際にファーストクラスの関数があるのなら、何でもかんでもクラスとメソッドの鋳型につっこむ代わりに、その作業に向いているならどんな方法であれ、そいつを使えるはずじゃないか。


これが言語の設計で意味することは、あまりオブジェクト指向プログラミングを深いところに組み込むなということだと思う。たぶん正解は、より一般的で基礎的な言語を作り、ユーザには、彼らがライブラリとして望むオブジェクトのシステムの設計を許すことだ。




3. 設計委員会


設計委員会が言語を設計するのは大きな落とし穴なのだが、それは単にあなたが想像する理由で、ではない。委員会に設計させるとゴツゴツしたツギハギの設計を産むことになることはご存じの通りだ。だが重要なのは、委員会はリスクを冒さないということだ。1人で設計していれば、委員会ならば決して賛成しないような危険を冒すことができる。


良い言語の設計に危険を冒すことは必要なのだろうか? 「言語の設計では、一般の通念からあまり飛躍しないほうがいい」と多くの人は思うかもしれない。でも私はそれが真実ではないほうに賭ける。他のすべてのことでは、危険と報酬が比例する。どうして言語の設計では違ってなくちゃいけないの?