百年後の言語 | Paul Grahamのエッセイ

2003年4月

(このエッセイは、PyCon 2003での基調講演に基づいています。)

100年後の生活がどうなっているかを予測するのは難しい。確実に言えることはほんのわずかだ。誰もが空飛ぶ車を運転し、ゾーニング法が緩和されて数百階建ての建物が許可され、ほとんどの時間帯が暗く、女性は皆、武術の訓練を受けているだろう。ここでは、この絵の細部に焦点を当てたい。彼らは、空飛ぶ車を制御するソフトウェアを書くために、どのようなプログラミング言語を使うのだろうか？

これは、実際にこれらの言語を使うことになるからというよりも、運が良ければ、私たちが現在からその時点までの道のりにある言語を使うことになるからこそ、考える価値があるのだ。

種と同様に、言語も進化の木を形成し、行き止まりがあちこちに枝分かれしていると思う。これはすでに起こっていることを見ることができる。Cobolは、かつては人気があったにもかかわらず、知的子孫がいるようには見えない。それは進化の行き止まり、ネアンデルタール人の言語なのだ。

私はJavaも同様の運命をたどると予測している。時々、「Javaが成功する言語にならないと言うのはどういうことだ？すでに成功している言語じゃないか」というメールが届く。そして、Javaに関する書籍（特に個別の書籍）が占める棚のスペースや、仕事を得るためにJavaを学ばなければならないと信じている学部生の数で成功を測るなら、確かにそうだと認める。私がJavaは成功する言語にならないと言うとき、もっと具体的に言っていることがある。それは、JavaはCobolのように、進化の行き止まりになるということだ。

これはただの推測だ。私が間違っているかもしれない。ここで私が言いたいのは、Javaを否定することではなく、進化の木という問題を提起し、言語Xは木のどこにあるのかを人々に問いかけてもらうことだ。この質問をする理由は、100年後に私たちの幽霊が「ほら、言った通りだ」と言うためだけではない。主要な枝の近くにいることは、今プログラミングするのに適した言語を見つけるための有用なヒューリスティックだからだ。

どんな時でも、進化の木の主要な枝にいるのがおそらく一番幸せだろう。ネアンデルタール人がまだたくさんいた時でさえ、ネアンデルタール人であることは最悪だったに違いない。クロマニョン人は常にやって来て、あなたを殴り、食べ物を盗んでいただろう。

私が100年後の言語がどうなっているかを知りたいのは、今どの枝に賭けるべきかを知るためなのだ。

言語の進化は、枝が収束する可能性があるため、種の進化とは異なる。例えば、Fortranの枝は、Algolの子孫と合流しているようだ。理論的には、これは種にも可能だが、細胞よりも大きなものに起こった可能性は低い。

言語の場合、可能性の空間がより小さく、突然変異がランダムではないため、収束が起こりやすい。言語設計者は、他の言語のアイデアを意図的に取り入れる。

プログラミング言語の進化がどこに向かうのかを言語設計者が考えることは特に有用だ。なぜなら、それに応じて舵取りができるからだ。その場合、「主要な枝にとどまる」ことは、良い言語を選ぶ方法以上の意味を持つ。それは、言語設計に関する正しい決定を下すためのヒューリスティックになる。

すべてのプログラミング言語は、公理の役割を果たす基本的な演算子の集合と、残りの言語（原則としてこれらの基本的な演算子で記述できる）の2つの部分に分けることができる。

言語の長期的な生存において最も重要な要素は、基本的な演算子だと思う。残りの部分は変更できる。それは、家を買う際には何よりもまず場所を考慮すべきだというルールのようなものだ。他のものは後で修正できるが、場所は修正できない。

公理がうまく選択されているだけでなく、その数が少ないことも重要だと思う。数学者は常に公理についてそう感じてきた。数が少ないほど良いと。そして、彼らは何かを理解していると思う。

少なくとも、言語のコアを詳しく調べて、取り除くことができる公理がないかどうかを確認することは、有益な演習になるはずだ。私は長年の怠け者としてのキャリアの中で、がらくたががらくたを生むことを発見した。そして、ソフトウェアだけでなく、ベッドの下や部屋の隅でもこれが起こるのを見てきた。

進化の木の主要な枝は、最小かつ最もクリーンなコアを持つ言語を通るという予感がある。言語のより多くの部分をそれ自体で記述できればできるほど、良い。

もちろん、100年後のプログラミング言語がどうなっているかを尋ねること自体、大きな仮定をしている。100年後にも私たちはプログラムを書いているのだろうか？コンピュータに何をさせたいかを指示するだけではないのだろうか？

その分野では、これまでのところ大きな進展はない。私の推測では、100年後の人々も、私たちがプログラムとして認識するようなものを使って、コンピュータに何をすべきかを指示しているだろう。現在私たちがプログラムを書くことで解決しているタスクの中には、100年後にはプログラムを書かなくても解決できるものがあるかもしれないが、今日私たちが行っている種類のプログラミングは、依然としてかなり多く存在すると思う。

誰かが100年後のテクノロジーがどうなっているかを予測できると考えるのは、傲慢に思えるかもしれない。しかし、すでに50年近い歴史が私たちにはあることを忘れないでほしい。過去50年間で言語がどれほどゆっくりと進化してきたかを考えると、100年後を見据えることは理解できるアイデアだ。

言語の進化はゆっくりだ。なぜなら、言語は実際にはテクノロジーではないからだ。言語は表記法だ。プログラムは、コンピュータに解決してもらいたい問題を形式的に記述したものだ。したがって、プログラミング言語の進化の速度は、輸送や通信などよりも、数学的表記法の進化の速度に近い。数学的表記法も進化するが、テクノロジーに見られるような大きな飛躍はない。

100年後のコンピュータが何でできているにせよ、現在よりもはるかに高速になっていると予測しても安全だろう。ムーアの法則が引き続き機能すれば、7400京倍（73,786,976,294,838,206,464倍）高速になるだろう。それは想像するのが難しい。そして実際、速度の面で最も可能性の高い予測は、ムーアの法則が機能しなくなるということかもしれない。18ヶ月ごとに倍増するとされているものは、最終的には何らかの根本的な限界に突き当たる可能性が高い。しかし、コンピュータが非常に高速になると信じることに抵抗はない。たとえわずか100万倍高速になるだけであっても、プログラミング言語の基本ルールは大幅に変わるはずだ。とりわけ、現在では遅い言語と見なされている言語、つまり非常に効率的なコードを生成しない言語のための余地が広がるだろう。

それでも、一部のアプリケーションは依然として速度を要求するだろう。コンピュータで解決したい問題の中には、コンピュータによって作成されたものがある。例えば、ビデオ画像を処理する必要がある速度は、別のコンピュータが画像を生成できる速度に依存する。そして、本質的にサイクルを無制限に消費する能力を持つ別の種類の問題がある。それは、画像レンダリング、暗号化、シミュレーションだ。

一部のアプリケーションはますます非効率になる可能性がある一方で、他のアプリケーションはハードウェアが提供できるすべての速度を引き続き要求する場合、コンピュータが高速になるということは、言語がこれまで以上に幅広い効率をカバーする必要があることを意味する。私たちはすでにこれが起こっているのを見てきた。一部の人気のある新しい言語の現在の実装は、過去数十年の基準からすると驚くほど無駄が多い。

これはプログラミング言語だけで起こることではない。それは一般的な歴史的傾向だ。テクノロジーが向上するにつれて、各世代は前の世代が無駄だと考えていたことを行うことができる。30年前の人々は、私たちがどれほど気軽に長距離電話をかけるかに驚くだろう。100年前の人々は、荷物がいつかメンフィス経由でボストンからニューヨークに運ばれることにさらに驚くだろう。

高速なハードウェアが今後100年間で私たちに与えてくれる余分なサイクルがどうなるかを、私はすでに言うことができる。それらのほとんどすべてが無駄になるだろう。

私はコンピュータの能力が乏しい時代にプログラミングを学んだ。4KのTRS-80のメモリに収まるように、Basicプログラムからすべてのスペースを取り除いたことを覚えている。この途方もなく非効率なソフトウェアが、同じことを何度も何度も繰り返してサイクルを浪費していると思うと、何となく嫌な気分になる。しかし、私の直感は間違っていると思う。私は貧しい家庭で育ち、医者に行くような重要なことのためでさえ、お金を使うことに耐えられない人のようだ。

ある種の無駄は本当に不快だ。例えば、SUVは、燃料が枯渇することがなく、汚染も発生しない燃料で走っていたとしても、おそらく不快だろう。SUVが不快なのは、それが不快な問題の解決策だからだ。（ミニバンをより男らしく見せる方法。）しかし、すべての無駄が悪いわけではない。それをサポートするインフラストラクチャが整った今、長距離電話の分数を数えるのはケチに見え始める。リソースがあるなら、相手がどこにいようと、すべての電話を1つの種類の電話として考える方がエレガントだ。

良い無駄と悪い無駄がある。私が興味を持っているのは、良い無駄だ。それは、より多くのお金を使うことで、よりシンプルな設計を得ることができる種類の無駄だ。私たちは、新しい、より高速なハードウェアから得られるサイクルを無駄にする機会をどのように活用するのだろうか？

速度への欲求は、私たちの貧弱なコンピュータに深く根付いているため、それを克服するには意識的な努力が必要になるだろう。言語設計では、効率と引き換えに、ほんのわずかでも利便性を向上させることができる状況を意識的に探すべきだ。

ほとんどのデータ構造は、速度のために存在する。例えば、今日の多くの言語には、文字列とリストの両方がある。意味的には、文字列は要素が文字であるリストのほぼサブセットだ。では、なぜ別のデータ型が必要なのだろうか？実際には必要ない。文字列は効率のためだけに存在する。しかし、プログラムを高速に実行するために、言語のセマンティクスをハックでごちゃごちゃにするのは見苦しい。言語に文字列があることは、時期尚早の最適化のケースのように思える。

言語のコアを公理の集合と考えるなら、効率のためだけに、表現力を何も追加しない追加の公理を持つのは見苦しいはずだ。効率は重要だが、それがそれを得るための正しい方法だとは思わない。

その問題を解決する正しい方法は、プログラムの意味を実装の詳細から分離することだと思う。リストと文字列の両方を持つ代わりに、リストだけを持ち、コンパイラに最適化のアドバイスを与える方法を用意して、必要に応じて文字列を連続したバイトとして配置できるようにする。

プログラムのほとんどの部分では速度は重要ではないため、通常、この種のミクロ管理に煩わされる必要はないだろう。コンピュータが高速になるにつれて、これはますます当てはまるようになるだろう。

実装について言及しないことは、プログラムをより柔軟にするはずだ。プログラムの作成中に仕様は変更されるが、これは避けられないだけでなく、望ましいことでもある。

「エッセイ」という言葉は、フランス語の動詞「essayer」（試すという意味）に由来する。元来の意味でのエッセイは、何かを理解しようと試みるために書くものだ。これはソフトウェアでも起こる。私が思うに、最高のプログラムの中には、作者が書き始めたときに正確に何を書きたいのかわからなかったという意味で、エッセイだったものがある。

Lispハッカーは、データ構造を柔軟に扱うことの価値をすでに知っている。私たちはプログラムの最初のバージョンを、リストですべてを実行するように書く傾向がある。これらの最初のバージョンは非常に非効率であるため、それらが何をしているかを考えないように意識的な努力が必要になる。少なくとも私にとっては、ステーキを食べるには、それがどこから来たのかを考えないように意識的な努力が必要になるのと同じだ。

100年後のプログラマーが最も求めているのは、可能な限り少ない労力で信じられないほど非効率なバージョン1のプログラムをまとめることができる言語だ。少なくとも、それが私たちが現代の言葉でそれを説明する方法だ。彼らが言うのは、プログラミングしやすい言語が欲しいということだ。

非効率なソフトウェアは見苦しくない。見苦しいのは、プログラマーに不必要な作業をさせる言語だ。プログラマーの時間を無駄にすることが真の非効率であり、機械の時間を無駄にすることではない。コンピュータが高速になるにつれて、これはますます明らかになるだろう。

文字列を取り除くことは、すでに私たちが考えることができることだと思う。私たちはArcでそれを行い、それは成功しているようだ。正規表現として記述するのが難しい一部の操作は、再帰関数として簡単に記述できる。

このデータ構造の平坦化はどこまで進むのだろうか？良心的に心を広げている私でさえ、ショックを受ける可能性を考えることができる。例えば、配列を取り除くのだろうか？結局のところ、配列はキーが整数のベクトルであるハッシュテーブルのサブセットにすぎない。ハッシュテーブル自体をリストに置き換えるのだろうか？

それよりも衝撃的な見通しさえある。例えば、McCarthyが1960年に説明したLispには、数値がなかった。論理的には、数値の別の概念を持つ必要はない。なぜなら、数値はリストとして表現できるからだ。整数nは、n個の要素のリストとして表現できる。この方法で数学を行うことができる。ただ、耐えられないほど非効率なだけだ。

実際には、数値をリストとして実装することを提案した人はいなかった。実際、McCarthyの1960年の論文は、当時はまったく実装されることを意図していなかった。理論的な演習であり、チューリングマシンのよりエレガントな代替手段を作成する試みだった。誰かが予期せずこの論文を取り上げ、それを動作するLispインタープリターに翻訳したとき、数値は確かにリストとして表現されなかった。それらは、他のすべての言語と同様に、バイナリで表現された。

プログラミング言語は、基本的なデータ型として数値を取り除くほど進むことができるだろうか？これは真剣な質問としてではなく、未来とのチキンレースをする方法として尋ねている。それは、抵抗できない力と不動の物体が出会うという仮説的なケースのようなものだ。ここでは、想像を絶するほど非効率な実装が、想像を絶するほど大きなリソースと出会う。そうでない理由がわからない。未来はかなり長い。コア言語の公理の数を減らすためにできることがあれば、それはtが無限大に近づくにつれて賭けるべき側のように思える。そのアイデアが100年後にも耐えられないように思えるなら、1000年後にはそうではないかもしれない。

これについて明確にするために、すべての数値計算が実際にリストを使用して実行されることを提案しているのではない。実装に関する追加の表記の前に、コア言語がこのように定義されることを提案している。実際には、ある程度の数学を行いたいプログラムは、おそらく数値をバイナリで表現するだろう。しかし、これは最適化であり、コア言語のセマンティクスの一部ではない。

サイクルを浪費するもう1つの方法は、アプリケーションとハードウェアの間に多くのソフトウェアレイヤーを持つことだ。これも私たちがすでに起こっているのを見ている傾向だ。多くの最近の言語はバイトコードにコンパイルされる。Bill Woodsはかつて、経験則として、解釈の各レイヤーは速度で10倍のコストがかかると言った。この追加コストは柔軟性をもたらす。

Arcの最初のバージョンは、この種の多層的な遅さの極端なケースであり、それに対応する利点があった。それは、Common Lispの上に書かれた古典的な「メタサーキュラー」インタープリターであり、McCarthyの元のLisp論文で定義されたeval関数と明確な家族的類似性を持っていた。全体のコードはわずか数百行だったため、非常に理解しやすく、変更も簡単だった。私たちが使用したCommon LispであるCLisp自体は、バイトコードインタープリター上で実行される。したがって、ここでは2つのレベルの解釈があり、そのうちの1つ（最上位のもの）は驚くほど非効率的だったが、言語は使用可能だった。かろうじて使用可能だったことは認めるが、使用可能だった。

ソフトウェアを複数のレイヤーとして記述することは、アプリケーション内でも強力なテクニックだ。ボトムアッププログラミングとは、プログラムを一連のレイヤーとして記述することを意味し、各レイヤーは上のレイヤーの言語として機能する。このアプローチは、より小さく、より柔軟なプログラムを生み出す傾向がある。それはまた、聖杯である再利用性への最良のルートでもある。言語は定義上、再利用可能だ。アプリケーションのより多くの部分を、そのタイプのアプリケーションを記述するための言語にプッシュダウンできればできるほど、ソフトウェアのより多くの部分が再利用可能になる。

どういうわけか、再利用性のアイデアは1980年代にオブジェクト指向プログラミングに関連付けられ、反対の証拠があっても、それを振り払うことができないようだ。しかし、一部のオブジェクト指向ソフトウェアは再利用可能だが、それを再利用可能にしているのは、そのボトムアップ性であり、オブジェクト指向性ではない。ライブラリについて考えてほしい。それらは言語であるため、再利用可能だ。オブジェクト指向スタイルで書かれているかどうかは関係ない。

ちなみに、私はオブジェクト指向プログラミングの終焉を予測しているのではない。特定の専門分野を除いて、優れたプログラマーに提供するものはあまりないと思うが、大規模な組織にとっては抵抗できないものだ。オブジェクト指向プログラミングは、スパゲッティコードを記述するための持続可能な方法を提供する。それは、プログラムをパッチのシリーズとして蓄積することを可能にする。大規模な組織は常にこの方法でソフトウェアを開発する傾向があり、これは今日と同じように100年後にも当てはまるだろうと予想している。

未来について話している限り、並列計算について話す方が良いだろう。なぜなら、そのアイデアはそこに存在するように思えるからだ。つまり、いつ話していても、並列計算は未来に起こることのように思える。

未来はいつそれに追いつくのだろうか？人々は少なくとも20年間、並列計算を差し迫ったものとして語ってきたが、これまでのところプログラミングの実践にはあまり影響を与えていない。あるいは、影響を与えていないのだろうか？すでにチップ設計者はそれについて考える必要があり、マルチCPUコンピュータでシステムソフトウェアを記述しようとしている人々もそうする必要がある。

本当の問題は、並列処理が抽象化の梯子をどこまで上るかだ。100年後には、アプリケーションプログラマーにさえ影響を与えるのだろうか？あるいは、コンパイラ作成者が考えることだが、通常はアプリケーションのソースコードには見えないものになるのだろうか？

1つ確かなことは、並列処理の機会のほとんどが無駄になるということだ。これは、私たちが与えられる余分なコンピュータ能力のほとんどが無駄になるという、私のより一般的な予測の特殊なケースだ。基盤となるハードウェアの驚異的な速度と同様に、並列処理は明示的に要求すれば利用できるが、通常は使用されないものになると予想している。これは、100年後の並列処理の種類が、特別なアプリケーションを除いて、大規模な並列処理ではないことを意味する。通常のプログラマーにとっては、並行して実行されるプロセスをフォークできるようなものになるだろうと予想している。

そして、これはデータ構造の特定の実装を要求するのと同じように、プログラムのライフサイクルのかなり後半で、最適化しようとするときに行うことだ。バージョン1は通常、並列計算から得られる利点を無視するだろう。データ構造の特定の表現から得られる利点を無視するのと同じように。

特別な種類のアプリケーションを除いて、並列処理は100年後に記述されるプログラムに浸透することはないだろう。そうすれば時期尚早の最適化になるだろう。

100年後には、プログラミング言語はいくつ存在するのだろうか？最近、非常に多くの新しいプログラミング言語が登場しているようだ。その理由の一部は、ハードウェアが高速になったことで、プログラマーがアプリケーションに応じて、速度と利便性の間で異なるトレードオフを行うことができるようになったからだ。これが本当の傾向であるなら、100年後に私たちが持つハードウェアはそれをさらに増加させるはずだ。

それでも、100年後には広く使用されている言語はごくわずかしかないかもしれない。私がそう言う理由の一部は楽観主義だ。本当に良い仕事をした場合、遅いバージョン1を記述するのに理想的な言語を作成できると同時に、コンパイラへの適切な最適化のアドバイスがあれば、必要に応じて非常に高速なコードも生成できると思われる。したがって、私は楽観的なので、許容できる効率と最大の効率の間に大きなギャップがあるにもかかわらず、100年後のプログラマーはそれらのほとんどを網羅できる言語を持つだろうと予測するつもりだ。

このギャップが広がるにつれて、プロファイラーはますます重要になるだろう。現在、プロファイリングにはほとんど注意が払われていない。多くの人々は、高速なアプリケーションを入手する方法は、高速なコードを生成するコンパイラを作成することだと依然として信じているようだ。許容できるパフォーマンスと最大のパフォーマンスの間のギャップが広がるにつれて、高速なアプリケーションを入手する方法は、一方から他方への優れたガイドを持つことであることがますます明らかになるだろう。

私が言語がごくわずかしかないと言うとき、ドメイン固有の「小さな言語」は含めていない。そのような埋め込み言語は素晴らしいアイデアだと思うし、それらが普及することを期待している。しかし、それらはユーザーが基盤となる汎用言語を見ることができるほど十分に薄いスキンとして記述されることを期待している。

未来の言語を設計するのは誰だろうか？過去10年間で最もエキサイティングな傾向の1つは、Perl、Python、Rubyのようなオープンソース言語の台頭だ。言語設計はハッカーに引き継がれつつある。これまでの結果は乱雑だが、心強い。例えば、Perlには驚くほど斬新なアイデアがいくつかある。多くは驚くほど悪いが、それは常に野心的な努力に当てはまることだ。現在の突然変異の速度では、Perlが100年後にどのような進化を遂げるかは神のみぞ知る。

できない人が教えるというのは真実ではないが（私が知っている最高のハッカーの中には教授もいる）、教える人ができないことがたくさんあるのは真実だ。研究は、制約的なカースト制限を課す。学術分野では、取り組んでも良いトピックとそうでないトピックがある。残念ながら、許容できるトピックと禁止されているトピックの区別は、通常、研究論文で説明したときに作業がどれほど知的に聞こえるかに基づいており、良い結果を得るためにどれほど重要かには基づいていない。極端なケースはおそらく文学だろう。文学を研究している人々は、それを制作している人々にとって少しでも役立つことを言うことはめったにない。

科学では状況は改善されているが、許可されている種類の作業と、優れた言語を生み出す種類の作業との重複は、悲しいほど小さい。（Olin Shiversはこれについて雄弁に不満を述べている。）例えば、型は研究論文の尽きることのない源泉のように思えるが、静的型付けは真のマクロを排除しているように思える。それなしでは、私の意見では、どの言語も使用する価値がない。

傾向は、言語が「研究」としてではなく、オープンソースプロジェクトとして開発されるだけでなく、コンパイラ作成者ではなく、それらを使用する必要があるアプリケーションプログラマーによって設計される方向に向かっている。これは良い傾向のように思えるし、それが継続することを期待している。

100年後の物理学とは異なり、予測することはほぼ必然的に不可能だが、原則として、100年後のユーザーにアピールする言語を今設計することは可能かもしれないと思う。

言語を設計する1つの方法は、コンパイラがそれを翻訳できるかどうか、またはハードウェアがそれを実行できるかどうかに関係なく、書きたいプログラムを書き留めることだ。これを行うとき、無制限のリソースを想定できる。今日と同じように、100年後にも無制限のリソースを想像できるはずだ。

どのようなプログラムを書きたいだろうか？最も手間のかからないものだ。ただし、正確にはそうではない。プログラミングに関するあなたのアイデアが、現在使用している言語にすでに影響を受けていなければ、最も手間のかからないものだ。そのような影響は非常に広範囲に及ぶ可能性があるため、それを克服するには多大な努力が必要になる。私たちと同じくらい怠惰な生き物にとって、最も少ない労力でプログラムを表現する方法は明らかだと思うだろう。実際、何が可能かについての私たちのアイデアは、私たちが考えている言語によって制限されている傾向があるため、プログラムのより簡単な定式化は非常に驚くべきものに思える。それらは発見しなければならないものであり、自然に陥るものではない。

ここで役立つトリックの1つは、プログラムの長さを、それを記述するのにかかる労力の近似値として使用することだ。もちろん、文字数ではなく、異なる構文要素の数、つまり基本的に構文木のサイズだ。最短のプログラムが記述するのに最も手間のかからないプログラムであるとは必ずしも言えないかもしれないが、簡潔さという確固たる目標を目指す方が、手間をかけないという曖昧で近くにある目標を目指すよりも優れている。次に、言語設計のアルゴリズムは次のようになる。プログラムを見て、これをより短く記述する方法はないかと尋ねる。

実際には、想像上の100年後の言語でプログラムを記述することは、コアに近いほどさまざまな程度で機能するだろう。ソートルーチンは今すぐ記述できる。しかし、100年後にどのような種類のライブラリが必要になるかを今予測するのは難しいだろう。おそらく、多くのライブラリはまだ存在しないドメイン用になるだろう。例えば、SETI@homeが機能すれば、エイリアンと通信するためのライブラリが必要になるだろう。もちろん、彼らが十分に高度で、すでにXMLで通信している場合を除いて。

もう一方の極端な例として、コア言語を今日設計できるかもしれないと思う。実際、1958年にすでにほとんど設計されていたと主張する人もいるかもしれない。

もし100年後の言語が今日利用可能であれば、私たちはそれを使ってプログラミングしたいと思うだろうか？この質問に答える1つの方法は、振り返ってみることだ。もし現在のプログラミング言語が1960年に利用可能であったなら、誰もそれらを使用したいと思っただろうか？

ある意味では、答えはノーだ。今日の言語は、1960年には存在しなかったインフラストラクチャを前提としている。例えば、Pythonのようにインデントが重要な言語は、プリンター端末ではあまりうまく機能しないだろう。しかし、そのような問題を脇に置いて、例えば、プログラムはすべて紙に書かれていると仮定すると、1960年代のプログラマーは、私たちが現在使用している言語でプログラムを記述することを好んだだろうか？

そう思う。初期の言語のアーティファクトをプログラムとは何かという彼らのアイデアに組み込んでいた、想像力に欠ける人々の中には、問題があったかもしれない。（ポインタ演算を行わずにデータを操作するにはどうすればよいか？gotoなしでフローチャートを実装するにはどうすればよいか？）しかし、最も賢いプログラマーは、もし彼らがそれらを持っていたなら、今日の言語を最大限に活用することに問題はなかったと思う。

もし私たちが今100年後の言語を持っていたなら、それは少なくとも素晴らしい擬似コードになるだろう。それを使ってソフトウェアを記述するのはどうだろうか？100年後の言語は、一部のアプリケーションに対して高速なコードを生成する必要があるため、おそらく私たちのハードウェアで十分にうまく実行できるほど効率的なコードを生成できるだろう。100年後のユーザーよりも多くの最適化のアドバイスを与える必要があるかもしれないが、それでも全体的にはプラスになるかもしれない。

さて、2つのアイデアがある。それらを組み合わせると、興味深い可能性が示唆される。（1）100年後の言語は、原則として今日設計できる。（2）そのような言語が存在すれば、今日プログラミングするのに適しているかもしれない。これらのアイデアがこのように示されているのを見ると、100年後の言語を今書いてみようと思わないのは難しい。

言語設計に取り組んでいるときは、そのような目標を持ち、それを意識的に念頭に置いておくことが良いと思う。運転を学ぶとき、教えられる原則の1つは、車のボンネットを道路に描かれたストライプに合わせるのではなく、遠くの地点を目指して車を整列させることだ。たとえあなたが気にしているのが次の10フィートで起こることだけだとしても、これが正しい答えだ。プログラミング言語でも同じことができるはずだと思う。

注

Lisp Machine Lispは、宣言（動的変数の宣言を除く）は単なる最適化のアドバイスであり、正しいプログラムの意味を変更しないという原則を具現化した最初の言語だったと私は信じている。Common Lispは、これを明示的に述べた最初の言語だったようだ。

感謝

Trevor Blackwell、Robert Morris、Dan Giffinに、この草稿を読んでくれたことに感謝します。Guido van Rossum、Jeremy Hylton、そしてPyConでの講演に招待してくれたPythonクルーの残りのメンバーにも感謝します。