言語設計に関する5つの質問
Original2001年5月
(これは、2001年5月10日にMITで行われたプログラミング言語設計に関するパネルディスカッションのために私が作成したメモの一部です。)
1. プログラミング言語は人のためのもの。
プログラミング言語は、人々がコンピュータと話す方法です。コンピュータは、あらゆる明確な言語を話すことに喜びを感じるでしょう。高水準言語が存在する理由は、人々が機械語を扱えないからです。プログラミング言語の目的は、私たちの脆弱な人間の脳が詳細の塊に圧倒されないようにすることです。
建築家は、ある種の設計問題が他の問題よりも個人的であることを知っています。最もクリーンで抽象的な設計問題の1つは、橋を設計することです。そこでの仕事は、与えられた距離を最小限の材料で跨ぐことにほぼ限られています。スペクトルの反対側は、椅子を設計することです。椅子のデザイナーは、人間の尻について考える時間を費やさなければなりません。
ソフトウェアも同様に異なります。ネットワークを通じてデータをルーティングするためのアルゴリズムを設計することは、橋を設計するのと同じように素晴らしい抽象的な問題です。一方、プログラミング言語を設計することは、椅子を設計することのようです：人間の弱点に対処することがすべてです。
私たちのほとんどは、これを認めたくありません。数学的な優雅さを持つシステムを設計することは、私たちのほとんどにとって、人間の弱点に迎合するよりもはるかに魅力的に聞こえます。そして、数学的な優雅さには役割があります：ある種の優雅さは、プログラムを理解しやすくします。しかし、優雅さはそれ自体が目的ではありません。
そして、私は言語が人間の弱点に合わせて設計される必要があると言うとき、私は言語が悪いプログラマーのために設計される必要があるとは言っていません。実際、私はあなたが最高のプログラマーのために設計すべきだと思いますが、最高のプログラマーでさえ限界があります。すべての変数が整数の添字を持つ文字xである言語でプログラミングしたい人はいないと思います。
2. 自分自身と友人のために設計する。
プログラミング言語の歴史を振り返ると、最も優れた言語の多くは、その著者自身が使用するために設計されたものであり、最も劣悪な言語の多くは他の人が使用するために設計されたものでした。
言語が他の人のために設計されるとき、それは常に特定のグループの他の人々のためです：言語デザイナーほど賢くない人々です。そうすると、あなたを見下すような言語が生まれます。Cobolは最も極端な例ですが、多くの言語はこの精神に浸透しています。
それは、言語がどれだけ抽象的であるかとは関係ありません。Cはかなり低水準ですが、それはその著者が使用するために設計されており、それがハッカーに好まれる理由です。
悪いプログラマーのために言語を設計するという主張は、良いプログラマーよりも悪いプログラマーが多いということです。それはそうかもしれません。しかし、その少数の良いプログラマーは、ソフトウェアの不均衡に大きな割合を占めています。
私は、最高のハッカーが好きになる言語をどのように設計するかという質問に興味があります。私はこれが「良いプログラミング言語をどのように設計するか」という質問と同じだと思いますが、たとえそうでなくても、少なくとも興味深い質問です。
3. プログラマーにできるだけ多くの制御を与える。
多くの言語（特に他の人のために設計されたもの）は、 governessの態度を持っています：彼らはあなたが良くないと思うことをするのを防ごうとします。私は反対のアプローチが好きです：プログラマーにできるだけ多くの制御を与えます。
私が最初にLispを学んだとき、私が最も好きだったのは、それが私を対等なパートナーと見なしていたことです。それまでに学んだ他の言語では、言語と私のプログラムがあり、言語で書かれたもので、二つは非常に別々でした。しかし、Lispでは、私が書いた関数やマクロは、言語自体を構成するものとまったく同じでした。私は望むなら言語を書き換えることができました。それはオープンソースソフトウェアと同じ魅力を持っていました。
4. 簡潔さを目指す。
簡潔さは過小評価され、さらには軽蔑されることもあります。しかし、ハッカーの心の中を覗くと、彼らが本当にそれを愛していることがわかります。たとえば、APLでわずか数行のコードで驚くべきことができるとハッカーが愛情を持って語るのを何度聞いたでしょうか？私は、本当に賢い人々が本当に愛するものには注意を払う価値があると思います。
プログラムを短くするためにできることはほとんど何でも良いと思います。ライブラリ関数はたくさんあるべきです；暗黙的にできることはすべてそうすべきです；構文は欠点があるほど簡潔であるべきです；物の名前も短いべきです。
そして、短いべきなのはプログラムだけではありません。マニュアルも薄くあるべきです。マニュアルの良い部分は、明確化、留保、警告、特別なケースに費やされています。マニュアルを短くするように自分を強制すると、最良のケースでは、あまりにも多くの説明を必要とした言語の問題を修正することによってそれを行います。
5. ハッキングが何であるかを認める。
多くの人々は、ハッキングが数学であるか、少なくとも自然科学のようなものであればよいと願っています。私は、ハッキングは建築にもっと似ていると思います。建築は物理学に関連しています。建築家は倒れない建物を設計しなければなりませんが、建築家の実際の目標は、偉大な建物を作ることであり、静力学についての発見をすることではありません。
ハッカーが好きなのは、素晴らしいプログラムを作ることです。そして、少なくとも私たち自身の心の中では、素晴らしいプログラムを書くことは称賛に値することであることを思い出さなければなりません。この作業が研究論文の従来の知的通貨に簡単に変換できないときでさえです。知的には、プログラマーが愛する言語を設計することは、あなたが論文を発表できるアイデアを具現化したひどい言語を設計することと同じくらい価値があります。
1. 大きなライブラリをどのように整理するか？
ライブラリは、プログラミング言語のますます重要な要素になっています。彼らはまた大きくなっており、これは危険です。あなたが望むことを行うライブラリ関数を見つけるのにかかる時間が、自分で書くのにかかる時間よりも長い場合、そのすべてのコードはあなたのマニュアルを厚くするだけです。（Symbolicsのマニュアルはその一例です。）したがって、私たちはライブラリを整理する方法に取り組む必要があります。理想的には、プログラマーがどのライブラリ呼び出しが正しいことを行うかを推測できるように設計することです。
2. 人々は本当にプレフィックス構文を恐れているのか？
これは、私が何年も考えてきたオープンな問題であり、まだ答えを知らないという意味でのオープンな問題です。プレフィックス構文は、数学を除けば、私には完全に自然に思えます。しかし、Lispの人気のなさの多くは、単に馴染みのない構文を持っていることに起因している可能性があります。もしそれが真実であれば、それに対処するべきかどうかは別の問題です。
3. サーバーベースのソフトウェアには何が必要か？
私は、今後20年間に書かれる最もエキサイティングな新しいアプリケーションの多くは、サーバー上にあり、Webブラウザを通じてあなたと対話するプログラムであると思います。そして、これらの種類のプログラムを書くためには、いくつかの新しいものが必要かもしれません。
私たちが必要とする1つのことは、サーバーベースのアプリがリリースされる新しい方法のサポートです。デスクトップソフトウェアのように、年に1回または2回の大きなリリースを持つのではなく、サーバーベースのアプリは一連の小さな変更としてリリースされます。1日に5回または10回のリリースがあるかもしれません。そして、原則として、誰もが常に最新のバージョンを使用します。
プログラムをデバッグ可能に設計する方法を知っていますか？さて、サーバーベースのソフトウェアも同様に、変更可能に設計されなければなりません。簡単に変更できる必要があります、または少なくとも小さな変更と重要な変更が何であるかを知っている必要があります。
サーバーベースのソフトウェアにとって驚くべきことに役立つかもしれないもう1つのことは、継続です。Webベースのソフトウェアでは、継続渡しスタイルのようなものを使用して、Webセッションの本質的に状態を持たない世界でサブルーチンの効果を得ることができます。もしそれがあまりにも高価でなければ、実際の継続を持つことは価値があるかもしれません。
4. 発見するべき新しい抽象は何か？
これはどれほど合理的な希望かはわかりませんが、私が個人的に本当にやりたいことの1つは、新しい抽象を発見することです。つまり、第一級関数や再帰、さらにはキーワードパラメータを持つことと同じくらいの違いを生む何かです。これは不可能な夢かもしれません。これらのことはそれほど頻繁には発見されません。しかし、私は常に探しています。
1. あなたが望む言語を使用できます。
アプリケーションプログラムを書くことは、かつてデスクトップソフトウェアを書くことを意味していました。そして、デスクトップソフトウェアには、オペレーティングシステムと同じ言語でアプリケーションを書くという大きな偏見があります。したがって、10年前、ソフトウェアを書くことはほぼCでソフトウェアを書くことを意味していました。最終的に、伝統が進化しました：アプリケーションプログラムは異常な言語で書かれてはならない。
サーバーベースのソフトウェアは、この全モデルを吹き飛ばします。サーバーベースのソフトウェアでは、あなたが望む言語を使用できます。ほとんど誰もこれを理解していません（特にマネージャーやベンチャーキャピタリストは）。数人のハッカーはこれを理解しており、それが私たちがPerlやPythonのような新しいインディ言語について耳にする理由です。私たちは、PerlやPythonがWindowsアプリを書くために使用されているから耳にしているわけではありません。
私たちにとって、プログラミング言語の設計に興味がある人々として、私たちの仕事に対する実際の聴衆が今や潜在的に存在するということを意味します。
2. スピードはプロファイラーから来る。
言語デザイナー、または少なくとも言語実装者は、高速なコードを生成するコンパイラを書くのが好きです。しかし、私はこれがユーザーにとって言語を速くする理由ではないと思います。Knuthは、スピードは重要なのはほんの数か所のボトルネックだけだとずっと前に指摘しました。そして、これらのボトルネックがどこにあるかを推測することはできないことを試したことがある人は誰でも知っています。プロファイラーが答えです。
言語デザイナーは間違った問題を解決しています。ユーザーは速く実行するためのベンチマークを必要としません。彼らが必要とするのは、自分のプログラムのどの部分を再記述する必要があるかを示すことができる言語です。実際には、スピードはそこから来ます。したがって、言語実装者がコンパイラの最適化に費やすはずだった時間の半分を良いプロファイラーを書くことに費やすことができれば、純粋な利益になるかもしれません。
3. 言語の設計を推進するアプリケーションが必要です。
これは絶対的なルールではないかもしれませんが、最良の言語はすべて、書かれるアプリケーションと共に進化したようです。Cは、システムプログラミングのために必要な人々によって書かれました。Lispは部分的に記号的微分を行うために開発され、マッカーシーは始めることに非常に熱心で、1960年のLispに関する最初の論文でも微分プログラムを書いていました。
あなたのアプリケーションが新しい問題を解決する場合は特に良いです。それは、プログラマーが必要とする新しい機能を持つように言語を駆動する傾向があります。私は個人的に、サーバーベースのアプリケーションを書くのに適した言語を書くことに興味があります。
[パネル中、ガイ・スティールもこの点を指摘し、アプリケーションはあなたの言語のコンパイラを書くことから成り立ってはならないという追加の提案をしました。]
4. 言語は使い捨てプログラムを書くのに適している必要があります。
使い捨てプログラムとは、限られたタスクのために迅速に書くものです。周りを見渡すと、多くの大きくて真剣なプログラムが使い捨てプログラムとして始まったことがわかると思います。ほとんどのプログラムが使い捨てプログラムとして始まったとしても驚きません。したがって、一般的にソフトウェアを書くのに適した言語を作りたいのであれば、それは使い捨てプログラムを書くのに適している必要があります。なぜなら、それがほとんどのソフトウェアの幼虫段階だからです。
5. 構文は意味論に関連している。
構文と意味論は完全に別々であると考えるのが伝統的です。これは衝撃的に聞こえるかもしれませんが、彼らがそうでない可能性があります。私は、あなたが言語で望むものが、あなたがそれを表現する方法に関連しているかもしれないと思います。
最近、ロバート・モリスと話していて、彼は演算子のオーバーロードは中置構文のある言語でより大きな利点があると指摘しました。プレフィックス構文のある言語では、あなたが定義する関数は実質的に演算子です。あなたが作った新しいタイプの数のためにプラスを定義したい場合、単にそれらを加算する新しい関数を定義すればよいのです。中置構文のある言語でそれを行うと、オーバーロードされた演算子の使用と関数呼び出しの間に外観の大きな違いがあります。
1. 新しいプログラミング言語。
1970年代には、新しいプログラミング言語を設計することが流行していました。最近はそうではありません。しかし、サーバーベースのソフトウェアが新しい言語を再び流行させると思います。サーバーベースのソフトウェアでは、あなたが望む言語を使用できるので、誰かが実際に他の利用可能な言語よりも優れているように見える言語を設計すれば、リスクを取って使用する人々がいるでしょう。
2. タイムシェアリング。
リチャード・ケルシーは、最後のパネルで再び時代が来たアイデアとしてこれを挙げ、私は彼に完全に同意します。私の推測（そしてマイクロソフトの推測のようです）は、多くのコンピューティングがデスクトップからリモートサーバーに移動することです。言い換えれば、タイムシェアリングが戻ってきます。そして、言語レベルでそれをサポートする必要があると思います。たとえば、リチャードとジョナサン・リースがScheme 48内でプロセススケジューリングを実装するために多くの作業を行ったことを知っています。
3. 効率。
最近、コンピュータがついに十分に速くなったように思え始めていました。ますます、バイトコードについて聞くことが増えてきました。これは、少なくとも私にとっては、私たちが余分なサイクルを持っていると感じていることを示唆しています。しかし、サーバーベースのソフトウェアではそうはならないと思います。ソフトウェアが実行されるサーバーの費用を誰かが支払わなければならず、彼らが1台のマシンでサポートできるユーザーの数が彼らの資本コストの除数になります。
したがって、効率は重要になると思います。特に計算ボトルネックでは重要です。サーバーベースのアプリケーションは多くのI/Oを行うため、I/Oを迅速に行うことが特に重要です。
最終的には、バイトコードが勝利しないかもしれません。現在、サンとマイクロソフトはバイトコードの戦いを繰り広げているようです。しかし、彼らはプロセスに自分たちを挿入する便利な場所としてバイトコードを利用しているのであって、バイトコード自体が良いアイデアだからではありません。この全ての戦場が回避される可能性があります。それはちょっと面白いことになるでしょう。
1. クライアント。
これは単なる推測ですが、私の推測では、ほとんどのアプリケーションの勝利モデルは純粋にサーバーベースになるでしょう。すべての人があなたのクライアントを持っているという前提で動作するソフトウェアを設計することは、すべての人が正直であるという前提で社会を設計するようなものです。それは確かに便利ですが、決して起こらないと仮定しなければなりません。
Webアクセスの何らかの形を持つデバイスが急増すると思います。そして、それらについてあなたが仮定できるのは、単純なHTMLとフォームをサポートできることだけです。あなたの携帯電話にブラウザはありますか？あなたのパームパイロットに電話はありますか？あなたのブラックベリーはより大きな画面を持つようになりますか？あなたのゲームボーイでWebを閲覧できますか？あなたの時計で？私はわかりません。そして、すべてがサーバー上にあると賭けるなら、私は知る必要はありません。それはすべての頭脳がサーバーにある方がはるかに堅牢です。
2. オブジェクト指向プログラミング。
これは物議を醸すものであることは理解していますが、私はオブジェクト指向プログラミングがそれほど大きな問題ではないと思います。私は、ウィンドウシステム、シミュレーション、CADプログラムのような特定の種類のデータ構造を必要とする特定の種類のアプリケーションには適したモデルだと思います。しかし、なぜそれがすべてのプログラミングのモデルであるべきなのかは理解できません。
大企業の人々がオブジェクト指向プログラミングを好む理由の一部は、それが多くの仕事のように見えるものを生み出すからだと思います。たとえば、整数のリストとして自然に表現されるものは、今やすべての種類の足場や喧騒を持つクラスとして表現されることができます。
オブジェクト指向プログラミングのもう1つの魅力は、メソッドが第一級関数の効果をいくぶん与えることです。しかし、これはLispプログラマーにとっては古いニュースです。実際の第一級関数を持っていると、あなたはそれを手元のタスクに適した方法で使用することができ、すべてをクラスとメソッドの型にはめ込む必要はありません。
言語設計にとって、これはあまりにも深くオブジェクト指向プログラミングを構築すべきではないということを意味します。おそらく、より一般的な基盤を提供し、人々がライブラリとして望むオブジェクトシステムを設計できるようにするのが答えかもしれません。
3. 委員会による設計。
言語が委員会によって設計されることは大きな落とし穴であり、誰もが知っている理由だけではありません。誰もが知っているように、委員会は不均一で一貫性のない設計を生み出す傾向があります。しかし、私はより大きな危険が、彼らがリスクを取らないことだと思います。1人の人が責任を持つと、委員会が決して同意しないリスクを取ることができます。
しかし、良い言語を設計するためにリスクを取る必要があるのでしょうか？多くの人々は、言語設計は従来の知恵にかなり近くに留まるべきだと疑うかもしれません。私は、これは真実ではないと賭けます。人々が行う他のすべてのことでは、報酬はリスクに比例します。なぜ言語設計がそれと異なるべきなのでしょうか？