これは、Paul Graham： The Hundred-Year Language を、原著者の許可を得て翻訳・公開するものです。
<版権表示>
本和訳テキストの複製、変更、再配布は、この版権表示を残す限り、自由に行って結構です。
(「この版権表示」には上の文も含まれます。すなわち、再配布を禁止してはいけません)。
Copyright 2003 by Paul Graham
原文: http://www.paulgraham.com/hundred.html
日本語訳：Shiro Kawai (shiro ＠ acm.org)
<版権表示終り>
Paul Graham氏のエッセイをまとめた『ハッカーと画家』の
邦訳版が出版されました。
出版社の案内ページ
Amazon.co.jp
サポートページ
2003/04/15 翻訳公開
2003/04/16 Yoshinori Okuji氏より訳語の訂正を頂き、反映 (「定理」→「公理」)
2003/04/18 武井伸光氏より誤記の訂正を頂き、反映
(この記事はPyCon 2003で 行った基調講演をもとに書いたものである)
100年後の生活というものを予測するのは難しい仕事だ。 確信を持って言えることなどほんの少ししかない。 人々は飛行自動車で飛び回り、 建築規制が緩和されて数百階建てのビルがそびえ立ち、 なぜだかいつも薄暗くて、 女性はみな武術を身につけているだろうとか、そのくらいのものだ。 今日は、その100年後の世界の中でも、あるひとつの点に注目したい。 そんな飛行自動車の制御をするソフトウェアを書くのに、 人々はどんなプログラミング言語を使うのだろう?
将来我々がそういう言語を実際に使えるまで生きるってわけじゃないが、 こんなことを考えるのは、うまくすれば現在からそこに至るまでの 道筋にある言語を使えるかもしれないからだ。
生物種と同様に、言語も枝分かれや行き止まりがそこらじゅうにある 進化の系統樹を形成する。既にその一部は現在でも観て取れる。 Cobolは、かつてあれだけ流行ったのに、知能ある子孫を残してはいないようだ。 それは進化の行き止まり、ネアンデルタール言語なんだ。
Javaも似たような運命をたどるのではないかと私は予測している。 時々、「Javaが成功する言語にならないなんて言うのはどうかしてるよ。 もう成功してるじゃないか」というようなメールを私に送って来る人がいる。 確かに、成功の度合いを本、それも個人所有の本が書棚を占有する幅だとか、 あるいは就職に必要だと信じてその言語を勉強する学部生の数で測るなら、 Javaは成功していると言えるだろう。 私がJavaは成功する言語にならないだろうと言うのは、 もう少し限定した意味においてだ。すなわちJavaは、 Cobolがそうであったように、進化の袋小路に向かうだろうということだ。
もちろんこれは単なる推測だ。間違っているかもしれない。 ここで言いたいのはJavaをけなすことじゃなくて、 言語の進化樹というものがあるということ、 そして言語Xはその樹のどこに位置するんだろうということを問うてもらいたいからだ。 この質問は、別に100年後にぼくらの幽霊が「ほらごらん、言った通りだろう」 なんていうためじゃない。樹のなるべく主要な枝に近くあることが、 現在プログラムを書くのに良い言語をみつける、経験的にうまい方法だからだ。
どんな時点でも、進化樹の主要な枝にいることは一番幸せなことだろう。 ネアンデルタール人がたくさん居た時だって、 ネアンデルタール人であることは決して良いことではなかったに違いない。 だっていつもクロマニヨン人がやってきて、 ぼこぼこにされて食糧を奪われていたのだから。
100年後のプログラミング言語がどうなっているかを考えたい理由は、 それによって現在のどの枝に賭けるべきかを知りたいからだ。
言語の進化が生物種の進化と違うのは、枝が再び交わることがあることだ。 例えばFortranの枝はAlgolの子孫と融合しつつある。理論的には生物種でも 有り得ることかもしれないが、今までに起こったことはたぶんなさそうだ。
言語で融合が起こりやすいのは、可能な空間が小さいからというのもあるし、 変異がランダムでないということもあるだろう。言語の設計者は意図的に 他の言語からアイディアを取り込む。
プログラミング言語の進化の向かう先について考えるのは、 言語の設計者にとっては特に有用だ。それによって方向を定めることができるからだ。 この場合、「主要な枝に乗ってゆく」ことは良い言語を選ぶためだけでなく、 言語設計において正しい選択を行うための良い経験則となるだろう。
どんなプログラミング言語も2つの部分に分けることができる。 公理の役割を持つ、根源的なオペレーターと、 原理的にそれらの根源的なオペレーターを使って書くことができる、残りの部分だ。
私が思うに、言語が長期間にわたって生き残るために最も重要な要素は、 この根源的なオペレータだ。残りの部分は変えることができる。 ちょうど、家を買う時には場所をまず熟考しなくちゃならないという法則と同じような ものだ。他の部分はいくらでも後から修正が効くが、場所だけは後から 動かすわけにはいかない。
さらに、公理は注意深く選ばれるだけでなく、なるべく少なくすることが 重要だと思う。「少ないほうが良い」と、数学者は公理に関していつもそう感じて来た。 そこには何か理由があると思う。
少なくとも、取り除ける公理が無いかどうか、言語のコアを注意深く調べることは 有効な練習になるだろう。ものぐさ人間としての長いキャリアの間に私は、 ホコリは次々とホコリを生んで行くということを発見したし、 それがベッドの下や部屋の隅だけでなく、ソフトウェアにおいても起きるという ことを目にして来た。
私の勘だが、進化樹の主要な枝は、最も小さくクリーンなコアを持つ言語を 通っているのだと思う。言語の残りの部分をその言語自身で書くことができる 余地が大きければ大きい程、良い。
もちろん、100年後のプログラミング言語がどんなだろうと尋ねる時点で 私はひとつの大きな仮定をおいている。 100年後には我々はプログラムなんてしているんだろうか? して欲しいことを言うだけでコンピュータがやってくれるようにならないんだろうか?
そっち方面では、これまでのところたいした進歩はない。 私の推測では、100年後でも、現在の我々がプログラムと呼ぶようなものを 使ってコンピュータにして欲しいことを伝えているだろう。 もちろん、現在の我々がプログラムを書いて解決している仕事のうち、 プログラムを書かないでも良くなるものはあるだろうが、 それでも現在の我々がやっているようなプログラムはまだ たくさん必要とされているだろうと思う。
どんな技術であれ、100年後を予想できるなんて考えるのは傲慢だと 思われるかもしれない。しかし、我々は既に50年の歴史を持っているということを 考えて欲しい。過去50年の言語の進化がいかにゆっくりとしたものであるかを 考えれば、100年後を見るということも考え得る範囲だろう。
言語がゆっくりと進化するのは、それが本当は技術ではないからだ。 言語は表記だ。プログラムは、コンピュータに解いて欲しいと思う問題の 正式な記述なんだ。だからプログラミング言語の進化の速度というのは、 移動手段や通信手段よりは、数学表記の進化に近いだろう。 数学の表記は確かに進化するが、技術の分野に見られるような 巨大な飛躍は無い。
100年後にコンピュータが何で作られていようが、 現在のものより遥かに速いと考えるのは安全な予測だろう。 ムーアの法則がこのまま続けば、コンピュータは現在の 7400京倍(73,786,976,294,838,206,464)の速度を得ることになる。 想像し難い数字だ。実際、速度の面ではムーアの法則は破れるだろう と考える方が無難な予想だ。18ヵ月毎に2倍になるなんてものは、 それが何であれ、いずれ根本的な限界に達しそうだと考えられる。 そうだとしても、コンピュータが現在のものよりずっとずっと速くなると 考えて良いだろう。たとえそれがたかだか100万倍であったとしても、 プログラミング言語の基本的な法則を大きく変えるには十分だ。 その中には、例えば現在では遅いと考えられている言語、 つまり効率的なコードを生成しない言語の活躍の余地が大きくなるということが 挙げられる。
もちろん、依然として速度を要求するアプリケーションもあるだろう。 コンピュータを使って解きたいと思う問題のいくつかは、 コンピュータ自身によって作られる。例えば、コンピュータで 生成されたビデオイメージの処理は、生成側のコンピュータの 速度に追い付いていなければならないだろう。 さらに、いくらマシンサイクルがあっても本質的にそれを喰い潰してしまう 類の処理というのがある。イメージレンダリング、暗号、シミュレーションといったものだ。
いくつかのアプリケーションはますます非効率になって行く一方で、 ハードウェアの限界までの速度を要求するアプリケーションがあるとすると、 速い計算機を手にするということは、言語は効率においてより広い範囲を カバーしなければならなくなるということだ。既にそれは起こりつつある。 人気のある新しい言語の現在の実装は、10年前の基準では驚異的に非効率だ。
これはプログラミング言語だけに起こっていることではない。 一般的な歴史の流れだ。技術が進むにつれ、 各世代はその前の世代だったらもったいないと思っていたようなことを 平気で出来るようになる。30年前の人は、我々がこんなに気軽に長距離電話をかけるのに 驚愕するだろう。100年前の人は、ボストンからニューヨークまで翌日配達便で 荷物を送るのに、メンフィスを経由すると聞いてひっくり返るだろう。
次の100年の間に、速いハードウェアによって我々が得る余分な マシンサイクルがどう使われるかを当ててみようか。 そのほとんどは無駄に使われることになる。
私は、コンピュータの力が貴重であった時代にプログラミングを学んだ。 4KバイトメモリのTRS-80に載せるために、Basicプログラムから全ての 空白を抜いたことを覚えている。同じ作業を何度も何度も繰り返すのに マシンサイクルを喰いつづける、おそろしく非効率なソフトウェアのことを 考えるのと気分が悪くなる。 だが、ここでは私の直観は間違っているんだろう。 貧乏が身についてしまうと、例えば医者にかかるといった重要なことに 金を使うのを躊躇してしまうようなものだ。
本当に気分の悪くなるような無駄があることは確かだ。 SUVは、例えそれが無公害で永遠に無くならないような燃料で走ったとしたって、 気持の良いものじゃない。それというのも、SUV自身が醜い問題への回答だからだ (ミニバンを何とかして逞しく見せようっていうね)。 でも、全ての無駄が悪いわけじゃない。 インフラが整った現在では、長距離電話をかける時に時間を分刻みで気にする なんて些細なことのように思えて来る。資源があれば、 相手がどこにいようと電話をかけるというのはひとつの均一な行為だと 考えるほうがエレガントだ。
良い無駄と悪い無駄があるってことだ。 私は良い無駄の方に関心がある。贅沢に使うことで、より単純なデザインが得られるような 無駄だ。新しい、速いハードウェアのマシンサイクルを無駄に使えるという チャンスをどんなふうに利用できるだろう。
貧弱なコンピュータを使っているうちに、速度への渇望は我々の中に あまりに深く刻み込まれてしまったため、それを乗り越えるには意識的な努力が 必要だ。言語の設計においても、少しでも便利にするために効率を犠牲にできる ところが無いかどうか、意識的に探さなければならない。
多くのデータ構造は速度のために存在する。 例えば、現代の言語の多くは文字列とリストを持っている。 意味的には、文字列は、全ての要素が文字であるというリストであって、 一般的なリストのサブセットと言える。 ならどうして別のデータタイプが必要なんだろう。 実は必要じゃないんだ。文字列は単に効率のためだけに存在している。 けれど、プログラムを速く走らせるハックのためだけに言語に意味をごてごてと 付け足すなんて、スマートじゃない。
言語のコアを公理の集合と考えると、 何ら表現能力を増やさない公理を効率のためだけに追加するというのは醜いことだ。 効率は重要だが、公理を追加することで達成するのは正しいやりかたとは思えない。
正しいやりかたは、プログラムの意味と実装の詳細を分けることだ。 リストと文字列を持つ代わりに、リストだけにしておいて、 コンパイラが必要なら文字列を連続したバイトとして表現できるような 最適化のアドバイスを与えられるようにしておくんだ。
大抵の、速度が問題じゃないプログラムにおいては、 こんな細かいことを気にする必要はないだろう。 コンピュータが速くなればなるほど、そういう場合は増えてくる。
実装を気にして書く必要が少なくなれば、プログラムはより柔軟になる。 プログラムを書いている最中に仕様が変わっても対応できる。 これは単に避け難いというだけでなく、望ましいことだ。
「エッセイ」という単語はフランス語の動詞 "essayer" から来ている。 それは「試す」という意味だ。エッセイは、もともとの意味においては、 何かを理解するために書いてみるものだった。 ソフトウェアも同じことだ。最良のプログラムのいくつかは、 作者が何を書くべきかはっきりわからないままに書きはじめたという 意味で、エッセイであると言えるだろう。
Lispハッカーは既にデータ構造を柔軟に持つことの価値を知っている。 最初のバージョンでは何もかもリストで処理するように書くことが多い。 こういった最初のバージョンはあまりにもおっそろしく非効率なんで、 そのプログラムが走っている時に何をしているのかを考えないように するには意識的な努力が必要だ。 私は、ステーキを食べている時にそれがどこから来たかをなるべく考えないように しているが、それと同じようなものだ。
100年後のプログラマが求めているものは、大抵の場合、 信じられない程非効率な最初のバージョンのプログラムを 最低限の努力ででっちあげられるような言語だろう。 現在の我々の言葉を使えば、だが。彼らに言わせれば、単に 「簡単にプログラムできる言語」ということになるだろう。
非効率なソフトウェアが醜いのではない。醜いのは、 プログラマに不要な仕事をさせる言語だ。本当の非効率性とは、 マシンの時間を無駄にすることではなく、 プログラマの時間を無駄にすることだ。 コンピュータが速くなればなるほど、このことははっきりしてくる。
文字列を取り除くことは、現在の我々にも何とか考え得る範疇にあると思う。 我々は既にArcで それをやってみて、結果は満足の行くものとなっている。 正規表現のような不器用な記述を要する処理も、再帰関数で簡単に書ける。
どこまでデータ構造をこんな具合に畳んでゆけるだろう? 意識的に想像力を押し広げることで、自分でも驚くくらいの可能性を 考えてみることができる。例えば、配列を取り除くことは出来るだろうか。 結局のところ、配列はハッシュテーブルのキーが整数のベクタであるものに過ぎない。 更に、ハッシュテーブルそのものをリストで置き換えることができるだろうか。
もっと驚くべき予測もできる。McCarthyが1960年に記述したLispには 数値が無かった。理論的には、数値というデータ型を別に持つ必要はない。 リストで表現できるからだ。整数NはN個の要素を持つリストで表現できる。 それを使って計算もできる。ただ、耐えがたいほど非効率なだけだ。
数値をリストで表現しようなんて真面目に提案した人はいなかった。 McCarthyの1960年の論文は、実装を意図したものでは無かったんだ。 それはチューリングマシンのよりスマートな代替を作ろうという、 理論的な演習であった。 その論文が実際に動作するLispインタプリタとして実装された時、 数値はリストで表されたわけではなかった。他の言語と同様に、 2進数が使われていたんだ。
プログラミング言語は基礎的なデータ型から数値を取り除くというところまで 行けるだろうか。これは真剣な質問じゃなく、むしろ未来にどこまで行けるかを 試してみる実験だ。動かせない物体に抗えない力を加えたらどうなるか という思考実験のようなものだ。信じ難いほど非効率な実装が、 信じ難いほど膨大な資源を使えたとしたら… ありえなくはないんじゃないか。 先は長いんだ。言語のコアの公理の数を減らすことが出来るものがあるとすれば、 tが無限大に近付くにつれ、いずれはそちらの方に向かってゆくんじゃないだろうか。 100年後にまだこのアイディアが許容できないとしたって、1000年後はどうなるか わからないよ。
一応断っておくが、私は何も数値計算を全てリストでやろうと 提案しているわけじゃない。実装に必要な追加の表記を加える前の、 コアの言語はこういうふうに定義すべきじゃないかと提案しているんだ。 現実には、数値計算を行うプログラムは数値を2進数で表現するだろうけど、 それは最適化とみなされるべきで、言語のコアの意味として考えられるべきじゃない。
マシンサイクルを浪費するもうひとつの方法は、ハードウェアとアプリケーション の間にたくさんの層を作ることだ。この流行は既に始まっている。 多くの新しい言語はバイトコードへとコンパイルされる。 Bill Woodsは、おおまかな目安として、一つ層を追加するとだいたい 10倍遅くなると私に言ったことがある。この追加のコストを払って 柔軟性を得ているわけだ。
最初のバージョンのArcはこの多層による遅いプログラムの極端な例だったが、 それに付随する利点もあった。それは古典的な「メタ巡回型」[訳註1] インタプリタで、Common Lispで書かれており、 McCarthyのもとのLisp論文のeval関数に極めて似たものだった。 全てはほんの200行ほどのコードで、だからすぐ理解できたし変更も容易だった。 我々が使ったCommon LispはCLispで、それ自身がバイトコードインタプリタで 動作していた。したがって我々は2つのインタプリタの層を持っていて、 しかもその一つ(上の層)はおそろしく非効率だったのだが、 それでも言語を使うことはできた。かろうじて、ではあったが。
ソフトウェアを複数の層に分けて書くのはアプリケーション内でも強力な テクニックだ。ひとつの層を次の層の記述言語として使って、 プログラムを層の積み重ねで構成してゆくのを、ボトムアッププログラミングという。 このアプローチを取ると、多くの場合プログラムはより小さく、 柔軟となる。またこの手法は、再利用性という聖杯に至る最良の路でもある。 言語は、その定義からして、再利用されるものだ。 アプリケーションのなるべく多くの部分を、そういう種類のアプリケーションを 書くための言語に落とし込んでゆくことで、あなたのソフトウェアはより 再利用がしやすくなる。
どういうわけか、1980年代に、再利用性という概念はオブジェクト指向プログラミングと くっついてしまって、どんなに反証をあげてもそこからひっぺがすことが できなくなってしまったようだ。確かにオブジェクト指向ソフトウェアの 中には再利用性の高いものがあるが、それはオブジェクト指向だからそうなのではなく、 ボトムアップ性があるからなんだ。ライブラリを考えてみたまえ。 オブジェクト指向スタイルで書かれていようがいまいが、 それが言語であるからこそ、再利用できるんじゃないか。
私はオブジェクト指向プログラミングの終焉を予言しようとしているんじゃないよ。 オブジェクト指向がプログラマに与えてくれるものは、 いくつかの特殊な領域を除いてはたいして無いと思っているけれど、 大きな組織にとっては抗い難い魅力があるのだろう。 オブジェクト指向プログラミングはスパゲッティコードを書くための持続的な方法を 提供してくれる。プログラムをパッチの繰り返しで書くことを加速するんだ。 大きな組織はソフトウェアをいつでもそういうふうに書いてきたし、 100年経ってもそれは変わらないだろう。
将来の話をするなら、並列計算にも触れておくべきだろう。 将来こそが並列計算にふさわしい場所だからだ。 つまり、いつの時代であっても、並列計算とは将来に来るものでありつづけるだろう ということなんだが。
未来はいつか並列計算に追い付くんだろうか? もうすぐ並列計算が来る、 と人々は少なくともこの20年は言い続けてきた。それでいてプログラミング作法には あまり影響を与えているようには思えない。 それとも影響はあるのか? 確かにチップ設計者は並列計算を考慮しなければ ならなくなっているし、マルチCPUのコンピュータの システムソフトウェアを書こうとする人もそうだ。
本当に知りたいのは、並列計算が抽象化の梯子をどのくらいまで登ってゆくだろう ということだ。100年後にはアプリケーションプログラマでさえも 影響を受けるだろうか。それともコンパイラを書く人だけが気にしていて、 アプリケーションのソースコードからは見えないものになるだろうか。
一つ、起こりそうなことは、並列化の機会の多くは無駄にされるだろう ということだ。これは、余分な計算能力の大部分が無駄になるだろうという 私の一般的な予測の特別な場合にすぎない。 基礎となるハードウェアがものすごく速くなった時代には、並列性は はっきり要求すれば使えるが、そうでなければ使われないというものに なるだろうと思っている。従って、特別なアプリケーションを除いては、 100年後に使われている並列計算は超並列計算ではないだろう。 普通のプログラマにとっては、プロセスを気軽に作って それがたまたま並列に走るとか、そういったものになるだろう。
そして並列計算も、特定のデータ構造の実装を指定するのと同じく、 プログラム開発のずっと後半、最適化を行う段階で導入するものになるだろう。 バージョン1は、特定のデータ表現から得られる利点を無視するのと同じように、 並列計算の利点をまったく無視したものになるだろう。
特別な種類のアプリケーションを除いて、 並列計算は100年後のプログラムにさほど影響を与えないだろう。 もし与えていたら、それは不適切な最適化になるだろう。
100年後には、プログラミング言語はいくつくらい存在するだろうか。 最近になってすごい数のプログラミング言語が生まれてきた。 理由のひとつは、ハードウェアが速くなったことで、プログラマが 速度と利便性の間にアプリケーションに応じて異なったトレードオフを 求められるようになったということだ。 この流れが本物ならば、100年後のハードウェアはこの傾向を後押しするだけだろう。
だが、100年後でも、広く使われる言語は2〜3個ではないかと 私には思われる。私の楽観性もあるのだが、もしうまくやれれば、 遅いバージョン1を書くのにも、また適切なアドバイスをコンパイラに 与えることによって必要なら非常に速いコードを生成するのにも、 理想的な言語というのを作れるんじゃないかと思っているからだ。 私は楽観的だから、まあまあの効率と最高の効率との解離が非常に大きく なるであろう時代でも、その多くの部分をカバーできる言語が できるだろうと予測する。
この解離が大きくなるにつれ、プロファイラーの重要性は増してゆく。 現在、プロファイリングに関してはほとんど注意が払われていない。 たくさんの人々が、 速いアプリケーションを得る方法は速いコードを出すコンパイラを書くことだと、 依然として信じている。 まあまあの効率と最高の効率との解離が進むにつれ、 前者から後者へと到る良いガイドを持つことが 速いアプリケーションを得る方法だということがはっきりしてくるだろう。
私は言語が2〜3個になるだろうと言ったが、 特定の領域に特化された「小さな言語」は含めていない。 そういう埋め込み言語は良いアイディアだと思うし、 きっと多くが生まれてくることだろう。 だが、それらの言語は、汎用の実装言語が透けてみえるくらいのごく薄い表皮として 書かれるようになるんじゃないかと思う。
未来の言語は誰が設計するだろう。 過去10年間の流れのうちもっともエキサイティングなもののひとつは、 Perl、Python、Rubyといったオープンソース言語の隆盛だ。 言語の設計がハッカーの手に渡ったんだ。 今の所、得られている結果はまだごちゃごちゃとしているが、期待できる。 例えばPerlにはいくつか、驚くほど新しいアイディアが見てとれる。 そのうちの大部分は驚くほど悪いが、それは野心的な努力にはつきものだ。 そして現在の変異の速度を考えるに、100年後にPerlがどうなっているか なんて誰にもわからない。
実行することができない者が教えるのだ、という謂は正しくない (私の知る最高のハッカーの幾人かは大学教授だ)。 しかし、教えることのできるものが実行できないことがあるというのは 正しいだろう。リサーチは 厳しいカーストの制限を受ける。どんな学問領域でも、 研究して良いテーマとそうでないテーマがある。 残念ながら、研究して良いテーマと禁じられたテーマの差異は、 良い結果を得るためにどれだけ重要かではなく、 論文にしたときにどれだけ知的に見えるかということで測られることが多い。 最も極端なのはおそらく文学だろう。文学を研究している人々が、 実際に文学を創り出している人々にちょっとでも役に立つことを言うことは ほとんどない。
科学ではまだ状況はましだが、研究でやれることと 良い言語を作ることの共通部分はがっかりするほど小さい。 (Olin Shiversがかつてこのことに対する不満を雄弁に語っていた)。 例えば、型は尽きせぬ論文の宝庫のようだが、 静的型付けは本物のマクロを排除するように見える---そして 私の意見では、本物のマクロの無い言語なんて使うに値しない。
言語が「研究」ではなくオープンソースプロジェクトとして開発されつつある という流れの他に、コンパイラ開発者でなく実際に言語を使うアプリケーション プログラマが言語を設計するようになって来たという流れがある。 これは良いことだと思うし、続いていって欲しい。
100年後の物理学は必然的にほとんど予測不可能だが、 100年後のユーザーを惹きつける言語を現在設計することは、 原理的に可能だと私は考える。
言語を設計するひとつの方法は、 その言語のコンパイラやそれを走らせるハードウェアがあるかないか ということを考えずに、こういうプログラムが書きたいんだ、というプログラムを 書いてみることだ。無制限の資源があると思って書いてみよう。 100年後でなく現在でも、無制限の資源を想像することはできるはずだ。
どんなプログラムを書きたいだろう。 なるべく少ない手間で書けるものだろう。 但し、あなたが現在使いなれた言語の影響を無くした上で、 少ない手間ということを考える必要がある。 そのような影響はあまりに深くて、それを乗り越えるには大きな努力が必要だ。 我々のような怠惰な生物にとって、プログラムを最低限の努力で表現する方法は 明白だと思うかもしれない。 実際は、何が可能かという点についての我々の考えは、 我々が考える言語によってあまりに制限されている。 だから、プログラムの簡単な記述法とは、当初予想もしなかったものになるだろう。 自然にそこに到るようなものではなく、発見しなければならないのだ。
有効な手法のひとつは、 プログラムの長さを、 それを書くのに必要な仕事量の目安に使うことだ。 ここでいう長さとは、もちろん文字数じゃなくて、構文要素の長さだ。 基本的には構文木の大きさということになる。 最も短いプログラムを書くのが最も楽だというのは必ずしも正しくないだろうが、 なんとなく楽な方法というのを探し求めるよりは、 明確な目標となり得るだろう。 すると、言語設計のアルゴリズムはこんなふうになる： プログラムを見て、これをもっと短く書く方法は無いかと考えるのだ。
実際には、この仮想的な100年後の言語でプログラムを書くという行為は、 どのくらい言語のコアに近いものを書いているかで大きく異なるだろう。 ソートルーチンならいまでも書ける。でも、100年後にどんなライブラリが 必要になるかを予測するのは難しい。たくさんのライブラリは 現在には存在さえもしていない領域のものになるだろうから。 例えば、もしSETI@homeが成功したならば、異星人と通信するための ライブラリが必要になるかもしれない。もちろん彼ら異星人が 十分に進化していて、XMLで通信し合っていなければ、の話だが。
逆の方向として、コア言語だけなら現在でも設計できるかもしれない。 実際、それは1958年に既になされたと主張する人さえいるだろう。
100年後の言語が今存在するとして、それでプログラムしたいと思うだろうか。 この問いに答える方法のひとつは、過去を振り返ってみることだ。 もし現在のプログラミング言語が1960年に存在したとして、 それでプログラムしたいと思う人がいただろうか。
ある意味で答えはノーだ。こんにちの言語は1960年には存在しなかった インフラを仮定している。例えばインデントに意味があるPythonのような 言語は、プリンタ端末では使いづらいだろう。 しかしそういう問題を脇においといて、例えば、プログラムは全部 紙に書かれるものだとして、1960年代のプログラマは現在我々が使っている プログラムで書くことを好むだろうか?
私はそう思う。想像力が十分でなく、 初期の言語の制限によってプログラムに関する考えが縛られてしまっている人には 難しいかもしれない。(ポインタ演算無しでどうやってデータを操作するんだ? goto無しでどうやってフローチャートを実装するんだ?) しかし、賢いプログラマなら、与えられれば現在のプログラム言語を 使いこなすことに何ら困難を感じないだろうと思う。
100年後の言語が今あったとすれば、すくなくとも疑似コードを 書くのに素晴らしい手段となるだろう。それを使ってソフトウェアを 書いてみるのはどうか。100年後の言語は少なくともある種のアプリケーションでは 速いコードを生成するはずだから、うまくすると現在のハードウェアでも どうにか走るくらいのコードが生成できるかもしれない。 100年後よりはたくさんの最適化のアドバイスを与えなければならないかも しれないが、総合的に見ればそのほうが良いかもしれない。
さあ、ここに2つのアイディアが出た。これを組み合わせると おもしろい可能性が見えてくる。(1)100年後の言語は、原理的には、 現在でも設計できる。(2)そのような言語は、もし存在すれば、 現在でもプログラムを書くのに良い言語かもしれない。 こんなふうにアイディアを並べて見ていると、 100年後の言語を、今、設計したくなってこないかい?
言語を設計する時には、そういうターゲットを設定して、常に頭に置いておく ことは良いことだと思う。運転を習う時、道路の線に車を合わせるのではなく、 遠くの点を目標にして方向を合わせると良いと教わるはずだ。 たとえ目先10フィートまでに起こることが重要なのだとしても、そのアドバイスは 正しい。プログラミング言語に関しても、それは同じだ。