言語設計に関する5つの質問 | Paul Grahamのエッセイ

2001年5月

（これは、2001年5月10日にMITで行われたプログラミング言語設計に関するパネルディスカッションのために作成したメモです。）

1. プログラミング言語は人のためにある。

プログラミング言語は、人がコンピュータと対話するための手段です。コンピュータは、曖昧さのない言語であればどんな言語でも同じように扱えます。私たちが高水準言語を使う理由は、人が機械語を扱えないからです。プログラミング言語の目的は、私たちのか弱い人間の脳が大量の詳細に圧倒されるのを防ぐことです。

建築家は、ある種のデザイン問題が他のものよりも個人的なものであることを知っています。最も洗練された抽象的なデザイン問題の一つは、橋の設計です。そこでは、与えられた距離を最小限の材料で架けることが主な仕事です。スペクトルのもう一方の端は、椅子の設計です。椅子のデザイナーは、人間の尻について考えることに時間を費やさなければなりません。

ソフトウェアも同様に異なります。ネットワークを介してデータをルーティングするためのアルゴリズムを設計することは、橋の設計のように、素晴らしく抽象的な問題です。一方、プログラミング言語を設計することは、椅子の設計に似ています。それはすべて、人間の弱点に対処することです。

私たちのほとんどは、これを認めたがりません。数学的に優れたエレガントなシステムを設計することは、人間の弱点に迎合するよりもはるかに魅力的に聞こえます。そして、数学的なエレガンスには役割があります。ある種のエレガンスは、プログラムを理解しやすくします。しかし、エレガンスはそれ自体が目的ではありません。

そして、言語は人間の弱点に合わせて設計されなければならないと言うとき、それは言語が悪いプログラマーのために設計されなければならないという意味ではありません。実際、最高のプログラマーのために設計すべきだと思いますが、最高のプログラマーでさえ限界があります。すべての変数が整数の添え字を持つ文字xである言語でプログラミングしたい人はいないと思います。

2. 自分自身と友人のために設計する。

プログラミング言語の歴史を見ると、最高の言語の多くは、作者自身が使用するために設計された言語であり、最悪の言語の多くは、他の人が使用するために設計された言語でした。

言語が他の人のために設計されるとき、それは常に特定のグループの他の人、つまり言語設計者ほど賢くない人です。そのため、あなたを見下すような言語が生まれます。Cobolが最も極端なケースですが、多くの言語がこの精神に満ちています。

それは、言語がどれほど抽象的であるかとは関係ありません。Cはかなり低レベルですが、作者が使用するために設計されたため、ハッカーはそれを好みます。

悪いプログラマーのために言語を設計するという議論は、良いプログラマーよりも悪いプログラマーの方が多いということです。それはそうかもしれません。しかし、それらの少数の優れたプログラマーが、ソフトウェアの不均衡に大きな割合を書いています。

私は、最高のハッカーが好む言語をどのように設計するかという質問に関心があります。私はこれが、優れたプログラミング言語をどのように設計するかという質問と同一であると考えていますが、そうでないとしても、少なくとも興味深い質問です。

3. プログラマーに可能な限り多くの制御を与える。

多くの言語（特に他の人のために設計された言語）は、家庭教師のような態度を持っています。つまり、彼らがあなたにとって良くないと思うことをあなたがするのを防ごうとします。私は反対のアプローチが好きです。プログラマーにできる限り多くの制御を与えてください。

私が最初にLispを学んだとき、私が最も気に入ったのは、それが私を対等なパートナーと見なしたことでした。それまで私が学んだ他の言語では、言語と、その言語で書かれた私のプログラムがあり、その2つは非常に分離されていました。しかし、Lispでは、私が書いた関数とマクロは、言語自体を構成するものとまったく同じでした。必要に応じて言語を書き換えることができました。それは、オープンソースソフトウェアと同じ魅力を持っていました。

4. 簡潔さを目指す。

簡潔さは過小評価され、軽蔑さえされています。しかし、ハッカーの心の中を覗いてみると、彼らが本当にそれを愛していることがわかります。たとえば、APLでは、わずか数行のコードで驚くべきことができると、ハッカーがどれだけ頻繁に語っているのを聞いたことがありますか？本当に賢い人が本当に愛しているものは、注意を払う価値があると思います。

プログラムを短くするためにできることはほとんどすべて良いと思います。ライブラリ関数はたくさんあるはずです。暗黙的にできることはすべてそうであるべきです。構文は欠点があるほど簡潔であるべきです。物事の名前さえ短くあるべきです。

そして、短くあるべきなのはプログラムだけではありません。マニュアルも薄くあるべきです。マニュアルの良い部分は、明確化、留保、警告、および特別なケースで占められています。マニュアルを短くすることを強制すると、最良の場合、多くの説明を必要とした言語のものを修正することによってそれを行います。

5. ハッキングが何であるかを認める。

多くの人は、ハッキングが数学であるか、少なくとも自然科学のようなものであることを望んでいます。私は、ハッキングは建築に似ていると思います。建築家は倒れない建物を設計する必要があるという意味で、建築は物理学に関連していますが、建築家の実際の目標は、静力学に関する発見をするのではなく、素晴らしい建物を建てることです。

ハッカーがやりたいことは、素晴らしいプログラムを作ることです。そして、少なくとも私たちの心の中では、素晴らしいプログラムを書くことは、研究論文の従来の知的通貨に簡単に翻訳されない場合でも、称賛に値することであることを覚えておく必要があります。知的に言えば、論文を発表できるアイデアを具現化したひどい言語を設計するのと同じくらい、プログラマーが愛する言語を設計することは価値があります。

1. 大きなライブラリをどのように整理するか？

ライブラリは、プログラミング言語のますます重要なコンポーネントになりつつあります。それらはまた、大きくなっており、これは危険な可能性があります。必要なことを行うライブラリ関数を見つけるのに、自分で書くよりも時間がかかる場合、そのコードはすべて、マニュアルを厚くするだけで何もしていません。（Symbolicsのマニュアルはその良い例でした。）したがって、ライブラリを整理する方法に取り組む必要があると思います。理想的には、プログラマーがどのライブラリ呼び出しが正しいことを行うかを推測できるように設計することです。

2. 人々は本当にプレフィックス構文を恐れているのか？

これは、私が何年も疑問に思っており、まだ答えを知らないという意味で、未解決の問題です。プレフィックス構文は、数学を除いて、私には完全に自然に思えます。しかし、Lispの不人気さの多くは、単に慣れない構文によるものである可能性があります。それが本当である場合、それについて何かをするかどうかは別の問題です。

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

今後20年間に書かれる最もエキサイティングな新しいアプリケーションの多くは、Webベースのアプリケーション、つまりサーバー上にあり、Webブラウザーを介してあなたと対話するプログラムになると思います。そして、これらの種類のプログラムを書くには、いくつかの新しいものが必要になるかもしれません。

必要なことの1つは、サーバーベースのアプリがリリースされる新しい方法のサポートです。デスクトップソフトウェアのように、年に1回または2回の大きなリリースを行う代わりに、サーバーベースのアプリは一連の小さな変更としてリリースされます。1日に5回または10回もリリースされることがあります。そして、原則として、誰もが常に最新バージョンを使用します。

プログラムをデバッグ可能にするように設計する方法を知っていますか？同様に、サーバーベースのソフトウェアも変更可能になるように設計する必要があります。簡単に変更できる必要があります。少なくとも、何が小さな変更で、何が重大な変更であるかを知っている必要があります。

サーバーベースのソフトウェアに役立つかもしれないもう1つのことは、驚くべきことに、継続です。Webベースのソフトウェアでは、継続渡しスタイルのようなものを使用して、Webセッションの本質的にステートレスな世界でサブルーチンの効果を得ることができます。高すぎなければ、実際の継続を持つ価値があるかもしれません。

4. 発見されるべき新しい抽象化は何ですか？

これがどれほど合理的な希望であるかはわかりませんが、個人的に本当にやりたいことの1つは、新しい抽象化を発見することです。つまり、ファーストクラス関数や再帰、さらにはキーワードパラメーターを持つことと同じくらい大きな違いを生むものです。これは不可能な夢かもしれません。これらのことはそれほど頻繁に発見されません。しかし、私はいつも探しています。

1. 好きな言語を使用できる。

アプリケーションプログラムを書くことは、デスクトップソフトウェアを書くことを意味していました。そして、デスクトップソフトウェアでは、オペレーティングシステムと同じ言語でアプリケーションを書くことに大きな偏りがあります。そのため、10年前、ソフトウェアを書くことは、ほとんどCでソフトウェアを書くことを意味していました。最終的に、アプリケーションプログラムは珍しい言語で書いてはならないという伝統が進化しました。そして、この伝統は非常に長く発展したため、管理者やベンチャーキャピタリストのような非技術的な人々もそれを学びました。

サーバーベースのソフトウェアは、このモデル全体を吹き飛ばします。サーバーベースのソフトウェアを使用すると、好きな言語を使用できます。ほとんど誰もこれをまだ理解していません（特に管理者やベンチャーキャピタリストは）。少数のハッカーがそれを理解しており、それがPerlやPythonのような新しいインディーズ言語について聞く理由です。人々がWindowsアプリを書くためにPerlとPythonを使用しているから、PerlとPythonについて聞いているのではありません。

プログラミング言語の設計に関心のある私たちにとって、これは、私たちの仕事に潜在的に実際的な聴衆がいることを意味します。

2. スピードはプロファイラーから来る。

言語設計者、または少なくとも言語実装者は、高速なコードを生成するコンパイラーを書きたいと思っています。しかし、これがユーザーにとって言語を高速にするものではないと思います。Knuthは、スピードが重要なのは、いくつかの重要なボトルネックだけであるとずっと前に指摘しました。そして、それを試したことがある人は誰でも、これらのボトルネックがどこにあるかを推測できないことを知っています。プロファイラーが答えです。

言語設計者は間違った問題を解決しています。ユーザーはベンチマークを高速に実行する必要はありません。必要なのは、自分のプログラムのどの部分を書き換える必要があるかを示すことができる言語です。それが実際にスピードが生まれる場所です。したがって、言語実装者がコンパイラーの最適化に費やすはずだった時間の半分を費やして、代わりに優れたプロファイラーを書くことができれば、正味の勝利になるかもしれません。

3. 言語の設計を推進するにはアプリケーションが必要。

これは絶対的なルールではないかもしれませんが、最高の言語はすべて、それらを使用して書かれていたアプリケーションと一緒に進化してきたようです。Cは、システムプログラミングに必要とした人々によって書かれました。Lispは、部分的に記号微分を行うために開発され、McCarthyは、1960年のLispに関する最初の論文でも微分プログラムを書いていたほど、始めることを熱望していました。

アプリケーションが新しい問題を解決する場合、それは特に良いことです。それは、プログラマーが必要とする新しい機能を言語に搭載する傾向があります。私自身は、サーバーベースのアプリケーションを書くのに適した言語を書くことに関心があります。

[パネルディスカッション中、Guy Steeleもこの点を指摘し、言語がコンパイラーを書くことを目的としていない限り、アプリケーションは言語のコンパイラーを書くことで構成されるべきではないという追加の提案をしました。]

4. 言語は使い捨てプログラムを書くのに適している必要がある。

使い捨てプログラムが何であるかを知っています。それは、限られたタスクのためにすぐに書くものです。周りを見回すと、多くの大規模で深刻なプログラムが使い捨てプログラムとして始まったことがわかると思います。_ほとんど_のプログラムが使い捨てプログラムとして始まったとしても驚かないでしょう。したがって、一般的なソフトウェアを書くのに適した言語を作成したい場合は、使い捨てプログラムを書くのに適している必要があります。なぜなら、それがほとんどのソフトウェアの幼虫段階だからです。

5. 構文はセマンティクスに関連付けられている。

構文とセマンティクスは完全に分離されていると考えるのが伝統的です。これは衝撃的に聞こえるかもしれませんが、そうではないかもしれません。言語で必要なものは、それをどのように表現するかに関連している可能性があると思います。

最近、Robert Morrisと話をしていましたが、彼は、演算子のオーバーロードは、インフィックス構文を持つ言語ではより大きな勝利であると指摘しました。プレフィックス構文を持つ言語では、定義する関数はすべて事実上演算子です。作成した新しい数値型にプラスを定義する場合は、それらを追加する新しい関数を定義できます。インフィックス構文を持つ言語でそれを行う場合、オーバーロードされた演算子の使用と関数呼び出しの間には、外観に大きな違いがあります。

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

1970年代には、新しいプログラミング言語を設計することが流行していました。最近はそうではありませんでした。しかし、サーバーベースのソフトウェアは、新しい言語を再び流行させると思います。サーバーベースのソフトウェアを使用すると、好きな言語を使用できるため、他の言語よりも実際に優れていると思われる言語を誰かが設計した場合、リスクを冒してそれを使用する人がいるでしょう。

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

Richard Kelseyは、前回のパネルで、その時が再び来たアイデアとしてこれを挙げましたが、私は彼に完全に同意します。私の推測（そしてMicrosoftの推測でもあるようです）は、多くのコンピューティングがデスクトップからリモートサーバーに移行するということです。言い換えれば、タイムシェアリングが復活します。そして、言語レベルでのサポートが必要になると思います。たとえば、RichardとJonathan ReesがScheme 48内でプロセススケジューリングを実装するために多くの作業を行ったことを知っています。

3. 効率。

最近、コンピューターはついに十分に高速になったように思われ始めていました。ますます多くのバイトコードについて聞くようになり始めており、少なくともサイクルを節約できると感じていることを意味します。しかし、サーバーベースのソフトウェアではそうではないと思います。誰かがソフトウェアが実行されるサーバーの代金を支払う必要があり、マシンごとにサポートできるユーザーの数が、資本コストの除数になります。

したがって、効率は、少なくとも計算のボトルネックでは重要になると思います。サーバーベースのアプリケーションは多くのi/oを行うため、i/oを高速に行うことが特に重要になります。

最終的には、バイトコードが勝利ではないことが判明するかもしれません。SunとMicrosoftは、現時点では一種のバイトコードの戦いに直面しているようです。しかし、彼らはバイトコードがプロセスに自分自身を挿入するのに便利な場所であるためそうしているのであり、バイトコード自体が良いアイデアであるためではありません。この戦場全体がバイパスされることが判明するかもしれません。それはちょっと面白いでしょう。

1. クライアント。

これは単なる推測ですが、ほとんどのアプリケーションにとって勝利のモデルは、完全にサーバーベースになると思います。誰もがあなたのクライアントを持つという前提で動作するソフトウェアを設計することは、誰もが正直であるという前提で社会を設計するようなものです。それは確かに便利ですが、それが決して起こらないと想定する必要があります。

何らかのWebアクセスを持つデバイスが急増すると思います。そして、それらについて想定できるのは、単純なhtmlとフォームをサポートできることだけです。携帯電話にブラウザはありますか？パームパイロットに電話はありますか？ブラックベリーの画面は大きくなりますか？ゲームボーイでWebを閲覧できますか？あなたの時計？私は知りません。そして、すべてがサーバー上にあることに賭ければ、知る必要はありません。すべての頭脳をサーバーに置く方がはるかに堅牢です。

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

これは物議を醸すものであることは承知していますが、オブジェクト指向プログラミングはそれほど大きな問題ではないと思います。ウィンドウシステム、シミュレーション、CADプログラムなど、特定の種類のデータ構造を必要とする特定の種類のアプリケーションにとっては優れたモデルだと思います。しかし、なぜそれがすべてのプログラミングのモデルであるべきなのかわかりません。

大企業の人がオブジェクト指向プログラミングを好む理由の一部は、それが多くの仕事のように見えるものを生み出すからです。たとえば、整数のリストとして自然に表現できるものを、あらゆる種類の足場と騒ぎのあるクラスとして表現できるようになりました。

オブジェクト指向プログラミングのもう1つの魅力は、メソッドがファーストクラス関数の効果の一部を与えることです。しかし、これはLispプログラマーにとっては古いニュースです。実際のファーストクラス関数がある場合は、クラスとメソッドの型にすべてを強制する代わりに、手元のタスクに適した方法で使用できます。

言語設計にとって、これは、オブジェクト指向プログラミングをあまり深く組み込むべきではないことを意味すると思います。おそらく、より一般的で基盤となるものを提供し、人々がライブラリとして必要なオブジェクトシステムを設計できるようにすることが答えです。

3. 委員会による設計。

言語を委員会に設計させることは大きな落とし穴であり、誰もが知っている理由だけではありません。委員会は、まとまりがなく、一貫性のない設計を生み出す傾向があることを誰もが知っています。しかし、より大きな危険は、彼らがリスクを冒さないことです。1人の人が担当している場合、委員会が決して同意しないリスクを冒すことができます。

優れた言語を設計するにはリスクを冒す必要がありますか？多くの人は、言語設計は従来の知恵にかなり近いものを守るべきものであると疑うかもしれません。私はこれが真実ではないと賭けます。人が行う他のすべてのことにおいて、報酬はリスクに比例します。なぜ言語設計は異なるのでしょうか？