(・・ )( 。。) まだ誰も翻訳してないよね。きっと大丈夫だよね。
Paul Grahamのサイトで最新のエッセーが公表された。Lispの方言を鋭意作成中と言うことだったのだけれど、それを公表したらしいです。
ちなみに私はLispのことがぜんぜんわからないので、間違いをしていても間違えていることに気づいていないです。おかしなことを言っていたら教えていただけるとありがたいです（→やや堅い印象になってしまっているから、後で手を加えるかも）
元記事→Arc’s Out。参考→ポール・グレアムが手がけるLisp言語Arcがまもなく公開？ – YAMDAS現更新履歴。
更新履歴:
ちなみに、私がこれまで翻訳したPaul Grahamのエッセー:
We’re releasing a version of Arc today, along with a site about it at arclanguage.org. This site will seem very familiar to users of Hacker News. It’s mostly the same code, with a few colors and messages changed.
今日、arclanguage.orgというサイトと一緒にArcをリリースした。このサイトはHacker Newsを利用している人にはとても親しみやすいものだろう。arclanguage.orgの大半は同じコードで、少し色とメッセージを変えただけだ。
Arc is still a work in progress. We’ve done little more than take a snapshot of the code and put it online. I spent a fews days cleaning up inconsistencies, but it’s still in the semi-finished state most software is, full of hacks and note-to-self comments about fixing them.
Arcは依然として発展の途上にある言語だ。コードのスナップショットを撮って、それをオンライン上に公開することしかしていない。私は数日を使ってつじつまの合わない部分を取り除いていたが、それでもArcは大半のソフトウェアのような半分完成した状態のままで、やっつけの仕事とバグについてのコメントでいっぱいの状態だ。
Why release it now? Because, as I suddenly realized a couple months ago, it’s good enough. Even in this unfinished state, I’d rather use Arc than Scheme or Common Lisp for writing most programs. And I am a fairly representative Lisp hacker, with years of experience using both. So while Arc is not the perfect Lisp, it seems to be better for at least some kinds of programming than either of the leading alternatives.
そのような状態でなぜ今Arcをリリースしたのかって？それは、数ヶ月前に突然気づいたことなんだけど、Arcが十分良いものに仕上がっているからさ。まだ未完成の状態でも、私はほとんどのプログラムを書く用途にSchemeやあるいはCommon LispではなくArcを用いるだろう。そして私はSchemeとCommon Lispという二つの言語をどちらも長年使ってきた経験を持つ、かなり典型的なLispハッカーだ。だからArcは完全なLispではないけれど、ArcはLisp実装を牽引している代表的な二つの言語のどちらよりも、少なくともいくつかの種類のプログラミング用途ではより良いものに思えるんだ。
I worry about releasing it, because I don’t want there to be forces pushing the language to stop changing. Once you release something and people start to build stuff on top of it, you start to feel you shouldn’t change things. So we’re giving notice in advance that we’re going to keep acting as if we were the only users. We’ll change stuff without thinking about what it might break, and we won’t even keep track of the changes.
私はArcをリリースすることについて心配していた。なぜなら、Arcが変化するのを止めさせる力が生まれてきて欲しくなかったからだ。いったん何かをリリースして、人々がそれを使って何かを作り始めたら、変更を加えてはいけないのではないかと感じ始めてくるものだ。だから、自分たちだけが唯一のユーザーなのだというように振る舞い続けるつもりだという告知を事前に出したんだ。
I realize that sounds harsh, but there’s a lot at stake. I went to a talk last summer by Guido van Rossum about Python, and he seemed to have spent most of the preceding year switching from one representation of characters to another. I never want to blow a year dealing with characters. Why did Guido have to? Because he had to think about compatibility. But though it seems benevolent to worry about breaking existing code, ultimately there’s a cost: it means you spend a year dealing with character sets instead of making the language more powerful.
その告知は酷に聞こえるということはわかっているけど、オープンにすることと天秤にかけられているものは多い。昨年の夏に私は Guido van Rossum のPythonについての講演に出かけて、そして彼は前年のほとんどの時間を文字列の表現をある形式から別な形式に変えることに費やしていた。なんで Guido はそうしなければならなかったのか？それは、彼が互換性について考えなければならなかったからだ。しかしそれでも、すでにあるコードをダメにすることを心配するのは好意的に思えるかもしれない。けれど結局はコストがかかる: 互換性について考えることは、一年かけて言語をもっと強力にする代わりに文字セットについて対処することを意味しているんだ。
Which is why, incidentally, Arc only supports Ascii. MzScheme, which the current version of Arc compiles to, has some more advanced plan for dealing with characters. But it would probably have taken me a couple days to figure out how to interact with it, and I don’t want to spend even one day dealing with character sets. Character sets are a black hole. I realize that supporting only Ascii is uninternational to a point that’s almost offensive, like calling Beijing Peking, or Roma Rome (hmm, wait a minute). But the kind of people who would be offended by that wouldn’t like Arc anyway.
ちなみに、それが理由となってArcはAsciiしかサポートしていない。カレントバージョンのArcをコンパイルしたMzSchemeは文字列の対処についてもっと進んだ計画がある。しかし、どのようにしてその計画をArcに取り込むのか考えるのに数日しかかからなかったかもしれないが、私はそれに時間を割かなかった。私は文字セットに対処することに一日でさえも割きたくはない。文字セットはブラックホールだ。Asciiしかサポートしないことは英語圏以外の人にとってはほとんど侮辱的とさえ思えるほど国際化の流れに反しているということは理解している。まるで「ベイジン」ではなく「ペキン」と呼んだり、「ローマ」を「ロゥム」と呼んだりすることに似て（うーん、ちょっと待って）*1。けれど、そうしたことで気分を害するような人はArcを好きにはならないだろう。
Arc embodies a similarly unPC attitude to HTML. The predefined libraries just do everything with tables. Why? Because Arc is tuned for exploratory programming, and the W3C-approved way of doing things represents the opposite spirit.
ArcはHTMLに似て政治的に正しくない態度を体現している。あらかじめ定義されたライブラリーは、HTMLのtableタグのようにあらゆることができる。それはなぜか？それはArcが探検的なプログラミングのために最適化されているからだ。そしてW3Cが推奨する方法はこれとは全く正反対の精神を体現している。
There’s a similar opposition between the use of lists to represent things and the use of “objects” with named, typed fields. I went through a stage, after I’d been programming in Lisp for 2 or 3 years, where I thought the old way of using lists to represent everything was just a hack. If you needed to represent points, surely it was better to declare a proper structure with x and y fields than to use a list of two numbers. Lists could contain anything. They might even have varying numbers of elements.
似たような対立が、リストを用いて物事を表現することと、名前をつけられ、型が決められた「オブジェクト」を用いて物事を表現することの間にある。Lispでプログラミングして2～3年してから、リストを用いてあらゆるものを表現するという古いやり方はずぼらな仕事だと考える経験をした。座標を表現する必要がある場合には、疑いの余地なく二つの数のリストを用いるよりもxとyフィールドを持った適切な構造を宣言する方が良いだろう。それに対して、リストは何でも含むことができて、可変の要素を持つことさえできる*2。
I was wrong. Those are the advantages of using lists to represent points.
私は間違えていた。それが座標を表すためにリストを使う利点なのだ。
Over the years my appreciation for lists has increased. In exploratory programming, the fact that it’s unclear what a list represents is an advantage, because you yourself are unclear about what type of program you’re trying to write. The most important thing is not to constrain the evolution of your ideas. So the less you commit yourself in writing to what your data structures represent, the better.
何年にも渡って、私のリストへの評価は増していった。探検的なプログラミングでは、リストが何を表すのかがはっきりしないという事実こそが利点なのだ。なぜなら、プログラマー自身がどんなタイプのプログラムを書こうとしているのかはっきりしていないからだ。一番大事なことは自分の考えの展開を妨げないことだ。その結果、プログラムを書いているときにデータ構造が何を表しているのかにかける時間が少なければ少ない方が、良いことになる。
Tables are the lists of html. The W3C doesn’t like you to use tables to do more than display tabular data because then it’s unclear what a table cell means. But this sort of ambiguity is not always an error. It might be an accurate reflection of the programmer’s state of mind. In exploratory programming, the programmer is by definition unsure what the program represents.
tableタグはHTMLにおけるリストだ。W3Cはtableタグを用いて表形式のデータを表示する以上のことを推奨していない。それを許してしまうと表のセルが何を意味しているのかが不明瞭になるからだ。しかし、この種の曖昧さは必ずしも誤りとは言えない。そうした使い方はプログラマーの精神状態を正確に写し取っているものかもしれないからだ。探検的なプログラミングでは、プログラマーは定義によりプログラムが何を表しているのか確信を持っていないのだ。
Of course, “exploratory programming” is just a euphemism for “quick and dirty” programming. And that phrase is almost redundant: quick almost always seems to imply dirty. One is always a bit sheepish about writing quick and dirty programs. And yet some, if not most, of the best programs began that way. And some, if not most, of the most spectacular failures in software have been perpetrated by people trying to do the opposite.
もちろん、「探検的なプログラミング」は「手早く汚い」プログラミングを婉曲的に言ったものにすぎない。そしてそのフレーズはほとんど冗長だ: 手早いということはほとんどの場合汚いことを意味しているように思えるからね。みんな手早く汚いプログラムを書くことに尻込みしてしまう。しかし、ほとんどとは言わないがいくつかの素晴らしいプログラムはそんな風にしてはじまった。そしてほとんどとは言わないが、いくつかのソフトウェアにおける非常に華々しい失敗を犯してきたのは、それとは正反対のことを行おうとした人々なのだ。
So experience suggests we should embrace dirtiness. Or at least some forms of it; in other ways, the best quick-and-dirty programs are usually quite clean. Which kind of dirtiness is bad and which is good? The best kind of quick and dirty programs seem to be ones that are mathematically elegant, but missing features– and particularly features that are inessential but deemed necessary for propriety. Good cleanness is a response to constraints imposed by the problem. Bad cleanness is a response to constraints imposed from outside– by regulations, or the expectations of powerful organizations.
このように経験は、汚さを受け止めるように言っているのだ。別な言い方をすれば、少なくともいくつかの種類の汚さを、だ。別な見方をすれば、良くできた手早く汚いプログラムはたいていの場合とてもきれいだ。どの種類の汚さが悪くて、どの種類が良いものなのか？最上の種類の手早く汚いプログラムは数学的に洗練されてはいるが、特徴を欠いているんだ―とりわけ本質的ではないけれど、礼儀作法のために必要と考えられるような特徴を。良いきれいさというのは、問題によって課せられる束縛に対する反応になっているということだ。悪いきれいさというのは、外部から課される束縛―規則、あるいは力の持った組織による期待といったもの―に対する反応になっているということだ。
I think these two types of cleanness are not merely separate, but in opposition to one another. “The rules,” whatever they are, are usually determined by politics; you can only obey them at the expense of mathematical elegance. And vice versa.
私が思うに、これら二つの種類のきれいさというのは単に別物だと言うだけでなく、互いに対立している。それが何であれ「規則」というのはたいていの場合政治によって決定される。規則に従うためには、数学的洗練を犠牲にしなければならない。そして、その逆もまた成り立つのだ。
Arc tries to be a language that’s dirty in the right ways. It tries not to forbid things, for example. Anywhere I found myself asking “should I allow people to…?” I tried always to say yes. This is not the sort of language that tries to save programmers from themselves.
Arcは正しい方法で汚い言語であろうとしている。たとえば、Arcは何も禁止しないように努めている。どんなことについても自分が「プログラマーに～を許すべきなのだろうか？」と考えていることに気づくと、私は常に「許すべきだ」と言うようにいつも努めている。Arcはプログラマー自身が犯したミスを取り繕うような種類の言語ではない。
The kind of dirtiness Arc seeks to avoid is verbose, repetitive source code. The way you avoid that is not by forbidding programmers to write it, but by making it easy to write code that’s compact. One of the things I did while I was writing Arc was to comb through applications asking: what can I do to the language to make this shorter? Not in characters or lines of course, but in tokens. In a sense, Arc is an accumulation of years of tricks for making programs shorter. Sounds rather unambitious, but that is in fact the purpose of high-level languages: they make programs shorter.
Arcが極力避けようとしている汚さは冗長で、反復的なソースコードだ。それを避ける方法は、プログラマーにそうしたコードを禁止することではなく、コンパクトなコードを書くのを容易にすることだ。Arcを書いているときに私がやったことの中の一つは、アプリケーションのソースコードを綿密にチェックして、こんな風に尋ねることだった: 「これを短くするためには、言語に対して私は何ができるのだろうか？」。文字列やプログラムの行といった点ではなく、トークンの点でだ。ある意味で、Arcはプログラムを短くするために数年かけて蓄積されたトリックの集まりみたいなものだ。かなり控えめに聞こえるかもしれないけれど、それが事実高級言語の目的なんだ: 高級言語はプログラムをより短くする。
Being dirty in the right ways means being wanton, but sleek. I don’t know if Arc can honestly be described in such enticing terms yet, but that’s the goal. For now, best to say it’s a quick and dirty language for writing quick and dirty programs.
正しい方法で汚いことは、奔放だけど洗練されていることを意味する。これまでのところ私はArcがうそいつわりなく、そんな魅惑的な形容をされるかはわからない。けれど、それが私の目標だ。今のところは、せいぜい「Arcは手早く汚いプログラムを書くための、手早く汚い言語だ」としか言えない。