百年の言語
Original2003年4月
(このエッセイはPyCon 2003での基調講演に基づいています。)
百年後の生活がどのようになるかを予測するのは難しいです。確実に言えることはほんの数つです。誰もが空飛ぶ車を運転し、建物が数百階建てになるようにゾーニング法が緩和され、ほとんどの時間が暗く、女性は皆武道を習得しているでしょう。ここでは、この絵の一つの詳細に焦点を当てたいと思います。彼らは空飛ぶ車を制御するソフトウェアを書くためにどのようなプログラミング言語を使用するのでしょうか？
これは、実際にこれらの言語を使用することになるかどうかというよりも、運が良ければこの時点からあの時点までの道のりで言語を使用することになるから、考える価値があります。
私は、種と同様に、言語も進化の木を形成し、至る所に行き止まりが分岐すると思います。これはすでに起こっているのが見えます。Cobolは、時折人気があるにもかかわらず、知的な子孫を持っていないようです。それは進化の行き止まりであり、ネアンデルタールの言語です。
私はJavaも同様の運命を辿ると予測します。時折、私に「どうしてJavaが成功した言語にならないと言えるのですか？すでに成功した言語です」と言ってくる人がいます。そして、私はそれが成功していることを認めます。特にそれに関する本の棚のスペースや、仕事を得るために学ばなければならないと信じている学部生の数で成功を測るならば。しかし、私がJavaが成功した言語にならないと言うとき、私はもっと具体的なことを意味しています。つまり、JavaはCobolのように進化の行き止まりになるということです。
これは単なる推測です。私は間違っているかもしれません。ここでの私のポイントはJavaを否定することではなく、進化の木の問題を提起し、人々に「言語Xは木のどこにあるのか？」と考えさせることです。この質問をする理由は、私たちの幽霊が百年後に「私はそう言った」と言えるためだけではありません。主な枝に近づくことは、今プログラミングに適した言語を見つけるための有用なヒューリスティックだからです。
ある時点で、あなたはおそらく進化の木の主な枝にいるときが最も幸せです。ネアンデルタール人がまだたくさんいた時代でも、彼らでいるのはつらかったに違いありません。クロマニョン人は常にやってきて、あなたを殴り、食べ物を奪っていたでしょう。
私が百年後の言語がどのようになるかを知りたい理由は、今どの枝に賭けるべきかを知るためです。
言語の進化は種の進化とは異なり、枝が収束することがあります。例えば、Fortranの枝はAlgolの子孫と合流しているようです。理論的には、種にも同様のことが起こる可能性がありますが、細胞以上の大きさのものには起こりにくいでしょう。
収束は言語にとってより可能性が高いのは、可能性の空間が小さいことと、突然変異がランダムでないためです。言語設計者は他の言語からのアイデアを意図的に取り入れます。
言語設計者にとって、プログラミング言語の進化がどこに向かうかを考えることは特に有用です。なぜなら、彼らはそれに応じて舵を取ることができるからです。その場合、「主な枝に留まる」ということは、良い言語を選ぶ方法以上の意味を持ちます。それは言語設計に関する正しい決定を下すためのヒューリスティックになります。
どんなプログラミング言語も、二つの部分に分けることができます。基本的な演算子の集合と、原則としてこれらの基本的な演算子で書かれることができる言語の残りの部分です。
私は、基本的な演算子が言語の長期的な生存において最も重要な要素であると思います。残りは変更可能です。それは、家を買うときにまず立地を考慮すべきというルールのようなものです。他のすべては後で修正できますが、立地は修正できません。
公理がよく選ばれているだけでなく、数が少ないことも重要だと思います。数学者は常に公理についてこのように感じてきました。少ない方が良いと。そして、彼らは何かに気づいていると思います。
少なくとも、言語のコアを注意深く見て、取り除くことができる公理があるかどうかを確認することは有用な演習であるはずです。私は長いキャリアの中で、無駄は無駄を生むことを発見しました。そして、私はこの現象がソフトウェアだけでなく、ベッドの下や部屋の隅でも起こるのを見てきました。
私は、進化の木の主な枝が最小で最もクリーンなコアを持つ言語を通過するという直感を持っています。言語の中で自分自身で書ける部分が多いほど、良いのです。
もちろん、私は百年後のプログラミング言語がどのようになるかを尋ねること自体に大きな仮定をしています。百年後に私たちはプログラムを書くのでしょうか？私たちはただコンピュータにやってほしいことを伝えるだけではないでしょうか？
その分野ではあまり進展がありません。私の推測では、百年後の人々は、私たちが今認識するプログラムを使ってコンピュータに何をすべきかを伝えるでしょう。今、プログラムを書くことで解決しているタスクがあり、百年後にはプログラムを書く必要がなくなるかもしれませんが、私は今行っているタイプのプログラミングがまだかなり残ると思います。
百年後の技術がどのようになるかを予測するのは傲慢に思えるかもしれません。しかし、私たちはすでに約50年の歴史を持っています。過去50年で言語がどれほどゆっくり進化してきたかを考えると、百年後を見据えることは理解できるアイデアです。
言語はゆっくり進化します。なぜなら、言語は本当に技術ではないからです。言語は表記法です。プログラムは、コンピュータに解決してほしい問題の形式的な説明です。したがって、プログラミング言語の進化の速度は、交通や通信の進化の速度とは異なり、数学的表記法の進化の速度に近いです。数学的表記法は進化しますが、技術に見られるような巨大な飛躍はありません。
百年後にコンピュータが何でできているかはわかりませんが、今よりもはるかに速くなると予測するのは安全です。ムーアの法則が続くなら、彼らは74クインティリオン（73,786,976,294,838,206,464）倍速くなるでしょう。それは想像しにくいです。実際、速度の面で最も可能性の高い予測は、ムーアの法則が機能しなくなることかもしれません。18か月ごとに倍増することが期待されるものは、最終的には何らかの根本的な限界に直面する可能性が高いです。しかし、コンピュータが非常に速くなることを信じるのに問題はありません。たとえ彼らがわずかに百万倍速くなるだけでも、それはプログラミング言語の基本的なルールを大きく変えるはずです。他のことの中でも、今は遅いと見なされる言語、つまり非常に効率的なコードを生成しない言語に対しても、より多くの余地が生まれるでしょう。
それでも、いくつかのアプリケーションは速度を要求します。私たちがコンピュータで解決したい問題のいくつかは、コンピュータによって作成されます。たとえば、ビデオ画像を処理する速度は、別のコンピュータがそれを生成する速度に依存します。そして、サイクルを無限に吸収する能力を持つ別のクラスの問題があります：画像レンダリング、暗号化、シミュレーションです。
いくつかのアプリケーションがますます非効率的である一方で、他のアプリケーションはハードウェアが提供できるすべての速度を要求し続けるため、より速いコンピュータは言語がますます広範囲の効率をカバーする必要があることを意味します。これはすでに起こっているのを見てきました。現在の人気のある新しい言語のいくつかの実装は、過去の数十年の基準から見ると驚くほど無駄です。
これはプログラミング言語にだけ起こることではありません。これは一般的な歴史的傾向です。技術が進歩するにつれて、各世代は前の世代が無駄だと考えたことを行うことができます。30年前の人々は、私たちが長距離電話をかけるのをどれほど気軽に行っているかに驚くでしょう。100年前の人々は、ボストンからニューヨークまでメンフィス経由でパッケージが移動することにさらに驚くでしょう。
私は、より速いハードウェアが次の百年で私たちに与えるすべての余分なサイクルがどうなるかをすでにお話しできます。それらのほとんどは無駄になるでしょう。
私はコンピュータの力が不足していたときにプログラミングを学びました。私は、4K TRS-80のメモリに収まるようにBasicプログラムからすべてのスペースを取り除いていたことを覚えています。同じことを何度も繰り返している無駄なソフトウェアがサイクルを消費しているのを考えると、なんだか気持ちが悪いです。しかし、私の直感はここでは間違っていると思います。私は貧しい環境で育った人のようで、重要なこと、たとえば医者に行くためにお金を使うことさえ耐えられません。
ある種の無駄は本当に不快です。たとえば、SUVは、決して尽きることのない燃料で動き、汚染を生成しない場合でも、議論の余地なく不快です。SUVは、ひどい問題に対する解決策だから不快です。（ミニバンをより男性的に見せる方法。）しかし、すべての無駄が悪いわけではありません。今やそれを支えるインフラがあるので、長距離電話の分を数えることは小さなことに思えます。リソースがあれば、相手がどこにいてもすべての電話を一つのものとして考える方がエレガントです。
良い無駄と悪い無駄があります。私は良い無駄に興味があります。つまり、より多くの費用をかけることで、よりシンプルなデザインを得られるような無駄です。新しい、より速いハードウェアから得られるサイクルを無駄にする機会をどのように活用するのでしょうか？
速度への欲求は、私たちの貧弱なコンピュータに深く根付いているため、それを克服するには意識的な努力が必要です。言語設計においては、効率をわずかな便利さの向上と交換できる状況を意識的に探すべきです。
ほとんどのデータ構造は速度のために存在します。たとえば、今日の多くの言語には文字列とリストの両方があります。意味的には、文字列は要素が文字であるリストのサブセットです。では、なぜ別のデータ型が必要なのでしょうか？実際には必要ありません。文字列は効率のためだけに存在します。しかし、プログラムを速く実行するためのハックで言語の意味を混乱させるのはダサいことです。言語に文字列があるのは、早すぎる最適化のケースのようです。
もし言語のコアを公理の集合と考えるなら、効率のためだけに表現力を追加しない追加の公理があるのは不快です。効率は重要ですが、それを得るための正しい方法ではないと思います。
その問題を解決する正しい方法は、プログラムの意味を実装の詳細から分離することだと思います。リストと文字列の両方を持つのではなく、リストだけを持ち、必要に応じて文字列を連続したバイトとして配置できるようにコンパイラに最適化のアドバイスを与える方法を持つのです。
プログラムのほとんどでは速度は重要ではないので、通常はこの種のマイクロマネジメントを気にする必要はありません。コンピュータが速くなるにつれて、これはますます真実になるでしょう。
実装について少なく言うことは、プログラムをより柔軟にするはずです。仕様はプログラムが書かれている間に変わります。これは避けられないだけでなく、望ましいことでもあります。
「エッセイ」という言葉は、フランス語の動詞「essayer」に由来し、「試す」という意味です。元々の意味でのエッセイは、何かを理解しようとするために書くものです。これはソフトウェアにも当てはまります。私は、最高のプログラムのいくつかはエッセイだったと思います。著者は、始めたときに正確に何を書こうとしているのかを知らなかったのです。
Lispハッカーはすでにデータ構造に柔軟性を持つことの価値を知っています。私たちは通常、プログラムの最初のバージョンをリストで全て行うように書きます。これらの初期バージョンは、あまりにも非効率的であるため、何をしているのかを考えないようにするには意識的な努力が必要です。少なくとも私にとっては、ステーキを食べることは、それがどこから来たのかを考えないようにする意識的な努力を必要とします。
百年後のプログラマーが最も求めるのは、最小限の努力で信じられないほど非効率的なプログラムのバージョン1を組み合わせることができる言語です。少なくとも、これは現代の用語で説明する方法です。彼らが言うのは、プログラミングが簡単な言語が欲しいということです。
非効率的なソフトウェアは不快ではありません。不快なのは、プログラマーに無駄な作業をさせる言語です。プログラマーの時間を無駄にすることが真の非効率であり、機械の時間を無駄にすることではありません。これは、コンピュータが速くなるにつれてますます明らかになるでしょう。
私は、文字列を排除することはすでに考える価値があると思います。私たちはArcでそれを行い、成功しているようです。正規表現として記述するのが不便な操作のいくつかは、再帰関数として簡単に記述できます。
このデータ構造の平坦化はどこまで進むでしょうか？私の意識的に広げられた心でも驚くような可能性を考えることができます。たとえば、配列を排除することはできるでしょうか？結局のところ、配列は整数のベクトルをキーとするハッシュテーブルのサブセットに過ぎません。ハッシュテーブル自体をリストに置き換えることはできるでしょうか？
それ以上に驚くべき展望もあります。たとえば、1960年にマッカーシーが説明したLispには数字がありませんでした。論理的には、数字の別の概念を持つ必要はありません。なぜなら、数字をリストとして表現できるからです。整数nはn要素のリストとして表現できます。この方法で数学を行うことができます。ただし、非常に非効率的です。
実際に数字をリストとして実装することを提案した人はいませんでした。実際、マッカーシーの1960年の論文は、当時は実装されることを意図していませんでした。それは理論的な演習であり、チューリングマシンに対するよりエレガントな代替を作成しようとした試みでした。誰かがこの論文を取り、実際に動作するLispインタープリタに翻訳したとき、数字は確かにリストとして表現されていませんでした。すべての他の言語と同様に、バイナリで表現されていました。
プログラミング言語は、基本的なデータ型として数字を排除するまで進むことができるでしょうか？これは真剣な質問というよりも、未来とチキンゲームをする方法として尋ねています。これは、抵抗できない力が動かざる物体に出会う仮定のケースのようです。ここでは、想像を絶するほど非効率的な実装が想像を絶するほどのリソースに出会うのです。私はそう思わない理由がありません。未来はかなり長いです。もしコア言語の公理の数を減らすためにできることがあるなら、それは無限大に近づくにつれて賭ける側のように思えます。もしこのアイデアが百年後に耐えられないように思えるなら、千年後には耐えられるかもしれません。
これを明確にするために言っておくと、すべての数値計算が実際にリストを使用して行われることを提案しているわけではありません。私は、実装に関する追加の表記法の前に、コア言語がこのように定義されるべきだと提案しています。実際には、数学を行いたいプログラムはおそらく数字をバイナリで表現するでしょうが、これは最適化であり、コア言語の意味の一部ではありません。
サイクルを無駄にする別の方法は、アプリケーションとハードウェアの間に多くのソフトウェア層を持つことです。これもすでに起こっている傾向です。最近の多くの言語はバイトコードにコンパイルされます。ビル・ウッズはかつて、経験則として、各解釈層は速度で10倍のコストがかかると言っていました。この追加のコストは柔軟性を買います。
Arcの最初のバージョンは、この種の多層的な遅さの極端なケースであり、対応する利点もありました。それは、マッカーシーの元のLisp論文で定義されたeval関数に明確な家族的類似性を持つ、Common Lispの上に書かれた古典的な「メタ循環」インタープリタでした。全体のコードは数百行しかなく、非常に理解しやすく、変更も簡単でした。私たちが使用したCommon Lisp、CLisp自体はバイトコードインタープリタの上で動作します。したがって、ここには二つの解釈層があり、そのうちの一つ（上の層）は驚くほど非効率的であり、言語は使用可能でした。ほとんど使用可能でしたが、認めますが、使用可能でした。
ソフトウェアを複数の層として書くことは、アプリケーション内でも強力な技術です。ボトムアッププログラミングは、プログラムを一連の層として書くことを意味し、それぞれが上の層のための言語として機能します。このアプローチは、より小さく、より柔軟なプログラムを生み出す傾向があります。また、それは再利用性という聖杯への最良のルートでもあります。言語は定義上再利用可能です。アプリケーションのより多くをそのタイプのアプリケーションを書くための言語に押し込むことができれば、ソフトウェアのより多くが再利用可能になります。
再利用性のアイデアは、1980年代にオブジェクト指向プログラミングに付随してしまったようで、反対の証拠があってもそれを振り払うことはできないようです。しかし、オブジェクト指向ソフトウェアの中には再利用可能なものもありますが、それを再利用可能にするのはそのボトムアップ性であり、オブジェクト指向性ではありません。ライブラリを考えてみてください。ライブラリは、オブジェクト指向スタイルで書かれているかどうかにかかわらず、言語であるため再利用可能です。
ちなみに、私はオブジェクト指向プログラミングの終焉を予測しているわけではありません。特定の専門分野を除いて、良いプログラマーにとってあまり提供するものはないと思いますが、大規模な組織には魅力的です。オブジェクト指向プログラミングは、スパゲッティコードを書く持続可能な方法を提供します。それは、プログラムを一連のパッチとして蓄積させることを可能にします。
大規模な組織は常にこの方法でソフトウェアを開発する傾向があり、私は百年後も今日と同じようにそうなると予想しています。
未来について話しているので、並列計算についても話すべきです。なぜなら、このアイデアが生きている場所だからです。つまり、いつ話しても、並列計算は未来に起こることのようです。
未来はそれに追いつくことができるでしょうか？人々は少なくとも20年間、並列計算が差し迫ったものであると話してきましたが、これまでのところプログラミングの実践にはあまり影響を与えていません。あるいは、そうではないのでしょうか？すでにチップ設計者はそれを考慮しなければならず、マルチCPUコンピュータ上でシステムソフトウェアを書く人々もそうしなければなりません。
本当の質問は、並列性が抽象化の階段のどこまで上がるかということです。百年後には、アプリケーションプログラマーにも影響を与えるでしょうか？それとも、コンパイラ作成者が考慮するが、通常はアプリケーションのソースコードには見えないものになるでしょうか？
一つ確実に言えることは、ほとんどの並列性の機会が無駄になるということです。これは、私のより一般的な予測の特別なケースであり、与えられた余分なコンピュータパワーのほとんどが無駄になるということです。私は、基盤となるハードウェアの驚異的な速度と同様に、並列性は明示的に要求すれば利用可能ですが、通常は使用されないものになると予想しています。これは、百年後の並列性が、特別なアプリケーションを除いて、大規模な並列性ではないことを意味します。普通のプログラマーにとっては、すべてが並列に実行されるプロセスをフォークすることができるようなものになるでしょう。
そして、これは、データ構造の特定の実装を要求することと同様に、プログラムのライフサイクルのかなり遅い段階で行うことになるでしょう。バージョン1は、通常、並列計算から得られる利点を無視し、特定のデータの表現から得られる利点も無視するでしょう。
特別な種類のアプリケーションを除いて、並列性は百年後に書かれるプログラムに浸透することはありません。そうであれば、それは早すぎる最適化です。
百年後にはどれだけのプログラミング言語が存在するでしょうか？最近、新しいプログラミング言語が非常に多く見られます。その理由の一部は、より速いハードウェアがプログラマーに速度と便利さの間で異なるトレードオフを行うことを可能にしたからです。これが本当の傾向であれば、百年後にはハードウェアがそれをさらに増加させるはずです。
それでも、百年後には広く使用される言語は数少ないかもしれません。私がそう言う理由の一部は楽観主義です。もし本当に良い仕事をすれば、遅いバージョン1を書くのに理想的な言語を作ることができ、適切な最適化アドバイスをコンパイラに与えれば、必要に応じて非常に速いコードも生成できるでしょう。したがって、私は楽観的なので、受け入れ可能な効率と最大効率の間に巨大なギャップがあっても、百年後のプログラマーはそのほとんどをカバーできる言語を持つと予測します。
このギャップが広がるにつれて、プロファイラーの重要性が増していくでしょう。現在、プロファイリングにはあまり注意が払われていません。多くの人々は、速いアプリケーションを得る方法は速いコードを生成するコンパイラを書くことだと信じているようです。受け入れ可能なパフォーマンスと最大パフォーマンスのギャップが広がるにつれて、速いアプリケーションを得る方法は、一方から他方への良いガイドを持つことだとますます明らかになるでしょう。
私が言う「数少ない言語」とは、ドメイン固有の「小さな言語」を含んでいません。このような埋め込み言語は素晴らしいアイデアだと思いますし、普及することを期待しています。しかし、私はそれらが一般目的の言語の下に見えるように、十分に薄いスキンとして書かれることを期待しています。
未来の言語を設計するのは誰でしょうか？過去10年間の最もエキサイティングな傾向の一つは、Perl、Python、Rubyのようなオープンソース言語の台頭です。言語設計はハッカーによって引き継がれています。これまでの結果は混沌としていますが、励みになります。たとえば、Perlには驚くべき新しいアイデアがいくつかあります。多くは驚くほど悪いですが、野心的な努力には常にそういうものです。現在の突然変異の速度で、神のみぞ知る、Perlが百年後にどのように進化するかはわかりません。
「できない人は教える」というのは真実ではありません（私が知っている最高のハッカーの中には教授もいます）が、教える人ができないことがたくさんあるのは真実です。研究は制約のあるカースト制限を課します。どの学問分野にも、取り組むことが許可されているトピックとそうでないトピックがあります。残念ながら、受け入れ可能なトピックと禁止されたトピックの区別は、通常、研究論文で説明されるときの知的な響きに基づいており、良い結果を得るためにどれほど重要であるかには基づいていません。極端な例はおそらく文学です。文学を研究している人々は、作品を生み出す人々にとってわずかでも役立つことを言うことはめったにありません。
科学の分野では状況は改善されていますが、許可されている作業の種類と良い言語を生み出す作業の種類の重なりは、非常に小さいです。（オリン・シバースはこれについて雄弁に不満を言っています。）たとえば、型は研究論文の尽きることのない源のようですが、静的型付けは真のマクロを排除するようです。私の意見では、マクロなしでは、どの言語も使用する価値がありません。
この傾向は、言語が「研究」ではなくオープンソースプロジェクトとして開発される方向に向かっているだけでなく、言語がそれを使用する必要があるアプリケーションプログラマーによって設計される方向に向かっています。これは良い傾向であり、私はそれが続くことを期待しています。
百年後の物理学はほぼ必然的に予測不可能ですが、原則的には、百年後のユーザーにアピールする言語を今設計することが可能かもしれません。
言語を設計する一つの方法は、コンパイラがそれを翻訳できるかどうか、またはそれを実行できるハードウェアがあるかどうかに関係なく、書きたいプログラムをそのまま書き下ろすことです。これを行うと、無限のリソースを仮定できます。今日、百年後と同様に無限のリソースを想像できるはずです。
どのようなプログラムを書きたいでしょうか？最も労力が少ないものです。ただし、正確には、現在のプログラミングに関するアイデアが、すでに使用している言語の影響を受けていなければ、最も労力が少ないものです。このような影響は非常に広範囲であるため、それを克服するには大きな努力が必要です。私たちのように怠惰な生き物にとって、最小限の努力でプログラムを表現する方法は明らかであると思うかもしれません。実際、私たちの可能性に関するアイデアは、私たちが考える言語によって非常に制限されています。そのため、プログラムのより簡単な表現は非常に驚くべきものに見えます。それは発見しなければならないものであり、自然に沈み込むものではありません。
ここで役立つトリックの一つは、プログラムの長さを、書くのにどれだけの労力がかかるかの近似値として使用することです。もちろん、文字数の長さではなく、異なる構文要素の長さ、基本的には構文木のサイズです。最短のプログラムが最も労力が少ないというのは完全に正しいわけではありませんが、簡潔さという確固たる目標を目指す方が、最小の労力というあいまいな近くの目標を目指すよりも良いです。そうすると、言語設計のアルゴリズムは、プログラムを見て「これを短く書く方法はあるか？」と尋ねることになります。
実際には、想像上の百年後の言語でプログラムを書くことは、コアにどれだけ近いかによって異なる程度で機能します。今書けるソートルーチンがあります。しかし、百年後にどのようなライブラリが必要になるかを予測するのは難しいでしょう。おそらく、多くのライブラリは、まだ存在しないドメインのためのものになるでしょう。たとえば、SETI@homeが機能すれば、エイリアンとの通信のためのライブラリが必要になります。もちろん、彼らがXMLで通信するほど進んでいる場合は別ですが。
その反対側では、コア言語を今日設計できるかもしれません。実際、1958年にはすでにほとんど設計されていたと主張する人もいるかもしれません。
もし百年後の言語が今日利用可能であれば、私たちはそれでプログラミングをしたいと思うでしょうか？この質問に答える一つの方法は、振り返ることです。もし現在のプログラミング言語が1960年に利用可能であったなら、誰かがそれを使いたいと思ったでしょうか？
ある意味で、答えは「いいえ」です。今日の言語は、1960年には存在しなかったインフラを前提としています。たとえば、インデントが重要な言語、Pythonのような言語は、プリンタ端末ではうまく機能しません。しかし、そのような問題を脇に置いておくと、たとえば、すべてのプログラムが単に紙に書かれていると仮定した場合、1960年代のプログラマーは、私たちが今使用している言語でプログラムを書くことを好んだでしょうか？
私はそう思います。想像力の乏しい人々の中には、初期の言語のアーティファクトがプログラムの概念に組み込まれているため、困難を抱えるかもしれません。（ポインタ算術を行わずにデータを操作するにはどうすればよいのか？gotoなしでフローチャートを実装するにはどうすればよいのか？）しかし、最も賢いプログラマーは、もし彼らがそれを持っていたなら、現代の言語を最大限に活用するのに問題はなかったと思います。
もし今百年後の言語があれば、それは少なくとも素晴らしい擬似コードになるでしょう。それを使ってソフトウェアを書くことはどうでしょうか？百年後の言語は、いくつかのアプリケーションのために速いコードを生成する必要があるため、おそらく私たちのハードウェアで受け入れ可能に動作するのに十分効率的なコードを生成できるでしょう。私たちは百年後のユーザーよりも多くの最適化アドバイスを与える必要があるかもしれませんが、それでも純粋な利益になるかもしれません。
今、私たちは二つのアイデアを持っています。これらを組み合わせると、興味深い可能性が示唆されます：（1）百年後の言語は原則として今日設計できる可能性があり、（2）そのような言語が存在すれば、今日プログラミングするのに良いかもしれません。これらのアイデアがそのように並べられると、百年後の言語を書くことを試みるべきではないかと思わざるを得ません。
言語設計に取り組むとき、私はそのような目標を持ち、それを意識的に心に留めておくことが良いと思います。運転を学ぶとき、教えられる原則の一つは、車を道路に描かれたストライプと整列させるのではなく、遠くのある点を目指して整列させることです。たとえあなたが次の10フィートで何が起こるかだけを気にしているとしても、これは正しい答えです。私は、プログラミング言語でも同じことができると考えています。