言語設計に関する5つの質問
Original2001年5月
(これは、2001年5月10日にMITで行われたプログラミング言語設計に関するパネルディスカッションのために私が作ったメモです。)
1. プログラミング言語は人々のためにある。
プログラミング言語は、人々がコンピュータと話す方法です。コンピュータは、曖昧でない限り、どんな言語でも喜んで話すでしょう。私たちが高水準言語を持っている理由は、人々が機械語を扱うことができないからです。プログラミング言語の目的は、私たち人間の貧弱で壊れやすい脳が大量の詳細に圧倒されないようにすることです。
建築家は、ある種の設計問題は他の問題よりも個人的であることを知っています。最もクリーンで抽象的な設計問題の1つは、橋の設計です。そこでは、あなたの仕事は、ほとんどの場合、与えられた距離を最小限の材料で渡すことです。スペクトルのもう一方の端は、椅子の設計です。椅子の設計者は、人間の尻について考える時間を費やさなければなりません。
ソフトウェアも同じように変化します。ネットワークを通じてデータをルーティングするためのアルゴリズムを設計することは、橋の設計のように、美しく抽象的な問題です。一方、プログラミング言語を設計することは、椅子を設計することのようです。それはすべて、人間の弱点を扱うことについてです。
私たちのほとんどはこのことを認めたくありません。数学的にエレガントなシステムを設計することは、人間の弱点をあざけり続けるよりも、私たちの大多数にとってはるかに魅力的に聞こえます。そして、数学的なエレガンスには役割があります。ある種のエレガンスは、プログラムを理解しやすくします。しかし、エレガンスはそれ自体が目的ではありません。
そして、言語は人間の弱点を満たすように設計されなければならないと言うとき、私は言語は悪いプログラマーのために設計されなければならないという意味ではありません。実際、私はあなたが最高のプログラマーのために設計するべきだと思いますが、最高のプログラマーでさえ限界があります。私は、すべての変数が整数添え字付きの文字xである言語でプログラミングしたい人はいないと思います。
2. 自分と友人のために設計する。
プログラミング言語の歴史を見ると、最高の言語の多くは、その作者自身が使用するように設計された言語であり、最悪の言語の多くは、他の人が使用するように設計された言語です。
言語が他の人々向けに設計されている場合、それは常に特定のグループの人々向けです。つまり、言語設計者ほど賢くない人々です。そのため、あなたを軽視する言語が得られます。Cobolは最も極端な例ですが、多くの言語はこの精神に満ち溢れています。
これは、言語がどれほど抽象的であるかとは関係ありません。Cは非常に低レベルですが、その作者が使用するように設計されており、それがハッカーに好まれる理由です。
悪いプログラマーのために言語を設計する議論は、良いプログラマーよりも悪いプログラマーが多いということです。それはそうかもしれません。しかし、それらの少数の優れたプログラマーは、ソフトウェアの不均衡に大きな割合を占めています。
私は、最高のハッカーが気に入るような言語をどのように設計するかという質問に興味があります。私は、これが良いプログラミング言語を設計する方法と同じであると考えていますが、そうでなくても、少なくとも興味深い質問です。
3. プログラマーに可能な限り多くの制御を与える。
多くの言語（特に他の人々向けに設計された言語）は、家庭教師のような態度を持っています。彼らは、あなたにとって良くないと考えることをするのを防ごうとします。私は反対のアプローチが好きです。プログラマーに可能な限り多くの制御を与えてください。
私が初めてLispを学んだとき、私が最も気に入った点は、それが私を同等のパートナーとみなしていたことです。それまでに学んだ他の言語では、言語があり、言語で書かれた私のプログラムがあり、2つは非常に別々でした。しかし、Lispでは、私が書いた関数とマクロは、言語自体を構成する関数とマクロと同じでした。私は望めば言語を書き直すことができました。それはオープンソースソフトウェアと同じ魅力を持っていました。
4. 簡潔さを目指す。
簡潔さは過小評価され、さらには軽蔑されています。しかし、ハッカーの心の奥底をのぞいてみると、彼らは本当にそれを愛していることがわかります。ハッカーが、たとえばAPLでは、わずか2行のコードで驚くべきことができるという話を熱心に語っているのを何回聞いたことがありますか？私は、本当に賢い人々が本当に愛するものは、注目に値すると考えています。
私は、プログラムを短くするためにできることはほとんどすべて良いと思います。多くのライブラリ関数があるべきです。暗黙的にできることは何でも暗黙的であるべきです。構文は過度に簡潔であるべきです。物事の名前でさえ短くするべきです。
そして、短いのはプログラムだけではありません。マニュアルも薄くする必要があります。マニュアルの多くは、明確化、留保、警告、特殊なケースに費やされています。マニュアルを短くしようとすると、最良の場合、説明を必要とする言語のものを修正することによって行われます。
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などの新しいインディ言語について聞く理由です。PerlやPythonについて聞いているのは、人々がそれらを使ってWindowsアプリを書いているからではありません。
これは、プログラミング言語の設計に興味のある私たちにとって、私たちの仕事に実際に聴衆がいる可能性があることを意味します。
2. 速度はプロファイラーから来る。
言語設計者、あるいは少なくとも言語実装者は、高速なコードを生成するコンパイラを書くのが好きです。しかし、私はこれがユーザーにとって言語を高速にするものではないと思います。クヌースは、速度はほんの一握りの重要なボトルネックでしか問題にならないと、長い間指摘していました。そして、試したことがある人なら誰でも知っているように、これらのボトルネックがどこにあるかを推測することはできません。プロファイラーが答えです。
言語設計者は、間違った問題を解決しています。ユーザーは、高速に実行されるベンチマークを必要としません。彼らが本当に必要とするのは、自分のプログラムのどの部分を書き直す必要があるかを示すことができる言語です。それが、実際には速度が生まれる場所です。そのため、言語実装者がコンパイラ最適化に費やす時間の半分を、代わりに良いプロファイラーを書くことに費やせば、正味の利益になるかもしれません。
3. 言語の設計を推進するアプリケーションが必要です。
これは絶対的なルールではないかもしれませんが、最高の言語はすべて、それらが使用されていたアプリケーションとともに進化したように思えます。Cは、システムプログラミングのためにそれを必要としていた人々によって書かれました。Lispは、部分的に記号微分を行うために開発され、マッカーシーはすぐに始めたいと思っていました。そのため、彼は1960年のLispに関する最初の論文でさえ、微分プログラムを書いていました。
あなたのアプリケーションが何らかの新しい問題を解決できれば、特に良いです。それは、プログラマーが必要とする新しい機能を言語に持たせる傾向があります。私は個人的には、サーバーベースのアプリケーションを書くのに適した言語を書きたいと思っています。
[パネルディスカッション中、ガイ・スティールもこの点を指摘し、アプリケーションは、言語がコンパイラを書くための言語である場合を除いて、言語のコンパイラを書くことではないという追加の提案をしました。]
4. 言語は使い捨てプログラムを書くのに適している必要があります。
使い捨てプログラムとは何かを知っていますか？それは、限られたタスクのためにすばやく書くものです。私は、あなたが周りを見れば、多くの大きく深刻なプログラムが使い捨てプログラムとして始まったことに気づくと思います。ほとんどのプログラムが使い捨てプログラムとして始まったとしても、私は驚かないでしょう。そのため、一般的にソフトウェアを書くのに適した言語を作りたいのであれば、それは使い捨てプログラムを書くのに適している必要があります。なぜなら、それはほとんどのソフトウェアの幼虫段階だからです。
5. 構文は意味論と関連しています。
構文と意味論は完全に別物であると考えるのが伝統的です。これは衝撃的かもしれませんが、そうではないかもしれません。私は、言語で何をしたいかは、それをどのように表現するかによって関連していると思います。
私は最近、ロバート・モリスと話していて、彼は、演算子のオーバーロードは、中置構文を持つ言語ではより大きな利点であると指摘しました。プレフィックス構文を持つ言語では、定義する関数はすべて、事実上演算子です。あなたが作った新しいタイプの数のプラスを定義したい場合、それらを足す新しい関数を定義するだけです。中置構文を持つ言語でそれを行う場合、オーバーロードされた演算子と関数呼び出しの使用には、外観上の大きな違いがあります。
1. 新しいプログラミング言語。
1970年代には、新しいプログラミング言語を設計することが流行していました。最近ではそうではありません。しかし、私はサーバーベースのソフトウェアが新しい言語を再び流行させると思います。サーバーベースのソフトウェアでは、好きな言語を使用できます。そのため、誰かが実際に他の利用可能な言語よりも優れているように見える言語を設計した場合、それを試してみる人がいるでしょう。
2. タイムシェアリング。
リチャード・ケルシーは、前回のディスカッションで、これは再び時代が来たアイデアだと述べており、私は彼に完全に同意します。私の推測（そしてマイクロソフトの推測のようです）は、多くのコンピューティングがデスクトップからリモートサーバーに移行することです。言い換えれば、タイムシェアリングが復活しました。そして、私は言語レベルでそれをサポートする必要があると思います。たとえば、リチャードとジョナサン・リースがScheme 48内でプロセススケジューリングを実装するために多くの作業を行ったことは知っています。
3. 効率。
最近では、コンピュータはついに十分に速くなったように思え始めていました。バイトコードについてますます聞くようになりました。これは、少なくとも私にとっては、私たちがサイクルを無駄にできるようになったことを意味します。しかし、サーバーベースのソフトウェアでは、そうではないと思います。誰かがソフトウェアを実行するサーバーの費用を支払う必要があり、マシンごとにサポートできるユーザー数は、資本コストの除数になります。
そのため、少なくとも計算上のボトルネックでは、効率が重要になると思います。サーバーベースのアプリケーションは多くのI/Oを行うため、I/Oを高速に行うことが特に重要になります。
最終的に、バイトコードが勝利ではない可能性があります。サンとマイクロソフトは、現在、一種のバイトコードの戦いを繰り広げているようです。しかし、彼らはそれをやっているのは、バイトコードがプロセスに自分自身を挿入する便利な場所だからであり、バイトコード自体が良いアイデアだからではありません。この戦場全体が回避される可能性があります。それはちょっと面白いでしょう。
1. クライアント。
これは単なる推測ですが、私の推測では、ほとんどのアプリケーションの勝利モデルは、純粋にサーバーベースになるでしょう。誰もがあなたのクライアントを持っているという前提でソフトウェアを設計することは、誰もが正直であるという前提で社会を設計することのようです。確かに便利でしょうが、それは決して起こらないと仮定する必要があります。
私は、何らかのWebアクセスを持つデバイスが乱立すると考えています。そして、それらについて仮定できることは、単純なhtmlとフォームをサポートできるということだけです。携帯電話にブラウザがありますか？Palm Pilotに電話がありますか？BlackBerryは画面が大きくなりますか？ゲームボーイでWebを閲覧できますか？あなたの時計で？わかりません。そして、すべてがサーバー上にあると賭ける必要はありません。すべてをサーバー上に置く方がはるかに堅牢です。サーバー上に脳があるからです。
2. オブジェクト指向プログラミング。
これは物議を醸すものだと認識していますが、オブジェクト指向プログラミングはそれほど大したことではないと思います。私は、ウィンドウシステム、シミュレーション、CADプログラムなど、特定の種類のデータ構造を必要とする特定の種類のアプリケーションには、優れたモデルだと思います。しかし、それがすべてのプログラミングのモデルであるべき理由がわかりません。
大企業の人々がオブジェクト指向プログラミングを好む理由の1つは、それが多くの仕事のように見えるものを生み出すからです。たとえば、整数のリストとして自然に表現できるものは、あらゆる種類の足場や慌ただしさを持つクラスとして表現できるようになりました。
オブジェクト指向プログラミングのもう1つの魅力は、メソッドが第一級関数の効果の一部を与えることです。しかし、これはLispプログラマーにとっては古いニュースです。実際に第一級関数がある場合、手元のタスクに適した方法でそれらを使用できます。クラスとメソッドの型にはめ込む必要はありません。
これは、言語設計にとって、オブジェクト指向プログラミングをあまり深く組み込まないことを意味すると私は思います。おそらく答えは、より一般的な基礎となるものを提供し、人々がライブラリとして好きなオブジェクトシステムを設計できるようにすることです。
3. 委員会による設計。
言語を委員会に設計してもらうことは、大きな落とし穴であり、それは誰もが知っている理由だけではありません。誰もが、委員会はでこぼこで一貫性のない設計を生み出す傾向があることを知っています。しかし、私は、彼らはリスクを冒さないということが、より大きな危険であると思います。1人が責任者である場合、彼は委員会が決して同意しないようなリスクを冒すことができます。
しかし、良い言語を設計するためにリスクを冒す必要があるのでしょうか？多くの人は、言語設計は、従来の知恵にかなり忠実に従うべきものであると疑うかもしれません。私は、これは真実ではないと思います。人々が他のすべてのことにおいて、報酬はリスクに比例します。なぜ言語設計だけが異なるのでしょうか？