http://www.paulgraham.com/gfaq.html
↓あまり興味ないけど、lionfan さんの先手を打ってやってみた。わざとかなり意訳してみた。それを除いても明らかに誤訳と思われる部分が 2、3 箇所はある。直したいひとは直して適当にうpしてください。ぼくはもう興味なし。
(original: First Priority: Core Language)
2008 年 2 月
目下、私にとって Arc 関連の至上命題はコア言語である。 コア言語とは、car や cdr といった原始的オペレータでもなく、かといって専門用途のライブラリ関数でもない部分、 つまり Common Lisp で言う mapcar, let, remove-if-not のようなオペレータのことだ。
Arc Challenge で述べたとおり、公理系から出発して「日常プログラミング完全」な言語 に至る最短経路が一つはあるはずで (訳注: 「完全」も「公理」と同様、数学の用語である)、 Arc の目標はそれを発見することだ。
公理系を変更することにはやぶさかでない。 有用な変更なのであればなおさらだ。 ただ、それはいつもいつも考えつくようなものではない。
いま私が公理とライブラリの中間へ目を向けている理由は、 その領域のオペレータこそプログラマの観点からすれば言語そのものだということにある。 それこそがプログラムの原材料なのだ。 Lisp が家だとすると、そうしたオペレータは玄関のドアであり、居間のソファであり、 食卓テーブルである。そこにちょっとしたデザインの違いが生じただけで、言語の働きは大いに影響されうる。
ここに気を取られていることについて色々と非難されているが、 私の考えではこれは重要かつ解決困難な問題なのである。 その難しさを示すひとつの例として、Lisp はもう 50 歳にもなろうというのに、 私の知る限りすべての Lisp 方言におけるコア・オペレータが最短経路にほど遠いという点を挙げよう。 たとえば cond マクロ。こいつには Lisp 1 からこのかた余計な括弧がびっしり付いてきて、それを誰も何ともしてこなかった。 if と cond を押しつぶしてひとつのオペレータにする Arc の技も、誰かがとっくに見つけていたっておかしくなかったのだが、 間違いなくそんな周知の事実はない。こんなことができると気づいたときは嬉しかったなあ。
Lisp のコアがそれほど遅い進化に甘んじてきた理由のひとつは、慣れである。 人はまず今あるオペレータで考える。 存在しないオペレータを使ってコードを書き直す方法について想像するには、意識的な努力が必要なのだ。
このことは、私がコードの大きさに注意を向ける理由の一部でもある。 長いということが外からの制約となるのだ (訳注: この段落かなり自信なし:コメント参照←なるほどねえ)。 「このコードに必要な長さの下限はどれぐらいだろう」と考えながら見てしまう人は、 限界まで短くする新オペレータの発見から一歩離れたところにいる。
Lisp コアの進化が遅いもうひとつの理由は、これが実装というより設計の問題だという点にある。 ほとんどのハッカーはその種の仕事ができないし、しようとも思わない。 そんなことをしてもハッカー仲間に威張れないし、職の安定にもつながらない。 1 日に 500 行のコードを吐き出すのではなくマイナス 20 行のときには、単に運がよかったと考えてしまうのだ (訳注: ここは誤訳かも)。 しかし設計に労力を払うのはくだらないことなどではない。 実際、Lisp がこれほど長続きしているのは、ひとつには McCarthy が偉大な設計者だったからだろう。 プログラミング言語を自然言語に似せようという無思慮な企てや当時のハードウェアのせいで 皆が妥協した言語を作っていた時代に、彼は小さくていつまでも色あせないものを作り出したのだ。 Lisp の美点はこの明察に負うところが大きい。 その輝きは、彼ほど才能に恵まれなかった後代の設計者たちの闇を通すと一層際立つ。
最初のリリースで Arc を DIS った人たちのジョークに、「McCarthy の再来だ」というのがあった。 こういう意味でないのは分かっているが、私は実のところ、彼のやっていた言語設計を、彼のやめたところから再開したいと思っている。
だから Arc ユーザに頼みがある。私が気まぐれにちょこちょこ変更を加えているように見えるとき、辛抱してほしいのだ。 今のところコアはすべてエンピツ書きの状態だと考えており、希望としては大幅な変更も可能であってほしい。 これだと Arc でプログラムを書くのは面倒極まりないことになるが、最終成果はそれに見合うものとなるはずだ。
Arc はウェブアプリ作成に便利なライブラリ (あまりに強力で、 文字列をサーバに保存する必要のある問題で他の言語と Arc を比べるのがズルいほどのライブラリ) を持ってはいるが、 現時点で焦点はそこにない。ウェブアプリを書いたのはすべて、コアに現実世界の圧力を加えるためだけだ。 それで、ウェブアプリの新アイディアも興味があるとはいえ、私が本当に聞きたいのは言語コアに実施できる新しいことである。
この高度に絞り込まれ選び抜かれた分野で新たなアイディアを考えるのは並大抵のことではないが、 報いの大きい仕事でもある。それに、我々が求めているものが存在することは分かっている。 定義からして、(公理から完全言語への) 最短経路はある。プラトニックな Lisp は岩塊のどこかにある。 なすべきは、そこまで削りつづけることだけなのだ。
「かなり自信なし」の段落、訳してみました。<br><br>それが私がコードの大きさにフォーカスしている理由の一部だ。長さは外的な制約だ。「こいつはどれだけ短くできるだろうか?」と考えながらコードを見るようになったら、コードを限界まで短くする新しい演算子を発見するまであと一歩だ。