Paul Grahamのこのエッセーを読んだ時には、次の様な富豪な言語設計は大分先にならないと受入れられないだろうと思っていました。

The Hundred-Year Language 多くのデータ構造は速度のために存在する。例えば、現代の言語の多くは文字 列とリストを持っている。意味的には、文字列は、全ての要素が文字であると いうリストであって、一般的なリストのサブセットと言える。ならどうして別 のデータタイプが必要なんだろう。実は必要じゃないんだ。文字列は単に効率 のためだけに存在している。けれど、プログラムを速く走らせるハックのため だけに言語に意味をごてごてと付け足すなんて、スマートじゃない。 言語のコアを公理の集合と考えると、何ら表現能力を増やさない公理を効率の ためだけに追加するというのは醜いことだ。効率は重要だが、公理を追加する ことで達成するのは正しいやりかたとは思えない。 正しいやりかたは、プログラムの意味と実装の詳細を分けることだ。リストと 文字列を持つ代わりに、リストだけにしておいて、コンパイラが必要なら文字 列を連続したバイトとして表現できるような最適化のアドバイスを与えられる ようにしておくんだ。 大抵の、速度が問題じゃないプログラムにおいては、こんな細かいことを気に する必要はないだろう。コンピュータが速くなればなるほど、そういう場合は 増えてくる。 実装を気にして書く必要が少なくなれば、プログラムはより柔軟になる。プロ グラムを書いている最中に仕様が変わっても対応できる。これは単に避け難い というだけでなく、望ましいことだ。

ところが、最近知ったHaskellという言語はPaul Grahamのいう通り文字列型はなく、文字列は文字のリストで表現します。しかも人気の言語になっていきそうです。… (ちなみに最近興味を持っているJOYという言語も同様ですね。) うーん、大量のCPUパワーがあれば人間のブレインパワーの消費を肩代わりしてくれるという感じでしょうか。 Gauche等、特定のScheme実装で、文字列を文字のリストとして表現できるんではないかと思ったんですが、Schemeの仕様を守れなくなりそうですね。 (list? str) がリストだと言われてしまうと、過去のプログラムが動かなくなりそうです。(string? str)を必ず先に評価していないと破綻するという。 そうか、よく考えるとHaskellはコンパイラ言語だから、最適化できるんですね。 でも、このままCPUが高速になっていけば、Paul Grahamのいう通りになっていくのかもしれませんね。