ポール・グレアム「Arcに関するよくある質問」を翻訳しました。原題は Arc FAQ で、原文はココです。なお翻訳にあたり、id:ttamo様のアドバイスをいただいております。ありがとうございます!! 英語に強いみなさま、アドバイスをよろしくお願いいたします。


Arcに関するよくある質問

Arc FAQ

どこで入手できますか?
Where do I get it?

Arclanguage.orgでどうぞ。
Arclanguage.org.


なぜ新たな言語をデザインする必要があるのですか?
Why do you need to design a new language?

もし我々が新たな言語をデザインする必要がないのなら、それこそ驚きだ。それは「プログラミング言語の設計はすでに解決された問題だ。完璧な言語の決定版が設計されたから」と言ってるようなものだからだ。私にはそうは思えない。とうてい思えない。未解決の問題が多くて、私の頭はくらくらしている。
It would be surprising if we didn't still need to design more languages. That would amount to saying that programming language design is now a solved problem, and that the final, perfect language has now been designed. It does not seem that way to me-- not by a long shot. The number of still open questions makes my head spin.


どうしてArcって名前なんですか?
Why is it called Arc?

この名前は「ボトムアップ・プログラミング」を参考にしている。これは言語をアプリに合わせてカスタム設計し、まぐさ(訳注: 門の上の横木)ではなくアーチのようにしなやかなプログラムを生み出したい、という意味だ。簡潔さも追求しているので、Archのhも取り去った。
The name is a reference to bottom-up programming. This means customizing the language to suit your application, yielding a program shaped like an arch, rather than a lintel. Since brevity is another aim, we lopped off the h.


なぜcarとcdrを残したのですか?
Why did you keep car and cdr?

他にいいアイデアがなかったからだ。firstとrestとか、headとtailを使っていたら誤解を招いていただろう。というのも、cons は基本的にはペアなのであって、リストは cons で作れるものの一例に過ぎないからだ。
Because we couldn't think of any better alternatives. It would have been misleading to use first and rest or head and tail, because conses are fundamentally pairs; lists are one thing you can build with them, but not the only thing.

あるペアの1番目、その残りを表現する英語は存在しない。どうしても名前を作らざるを得ないなら、carとcdrはかなり良い答えだ。短いし、同じ文字数だし、たとえばcadrのように、自然な合成語を作れるからだ。
There's no conventional name in English for the first and second halves of a pair. If you have to make up names, car and cdr are pretty good choices, because they're short and the same length and naturally composable (e.g. cadr).


Arcはオブジェクト指向ですか?
Is Arc object-oriented?

「オブジェクト指向」という言葉にはいろんな意味がある。半分ははっきりしているが、半分は間違っている
The phrase "object-oriented" means a lot of things. Half are obvious, and the other half are mistakes.

ユーザが定義する新たな関数も、組み込み関数のように扱われるのと同様、Lispではユーザが新たに定義する型も、あらかじめ言語に定義されている型のように扱えるべきだというのが私たちの信念だ。どんなプログラムも新しい型の定義として書くべくだとは思わない。
We believe Lisp should let you define new types that are treated just like the built-in types-- just as it lets you define new functions that are treated just like the built-in functions. We don't believe that every program should consist of defining new types.


どうして区切り文字をカッコ以外にしないんですか?
Why not use some other delimiter than parentheses?

いろいろ試した結果だ。[ ] と { }は、( ) よりも左右のピクセル数の差が少なく、方向がはっきりしないのでやめた。< >はトークンよりも長い表現を囲むのには適さないという理由でやめた。
We tried various possibilities. Square and curly brackets lose because they are less directional than parens (left and right differ in fewer pixels); < and > lose because they don't wrap around enough to enclose expressions longer than tokens.


<new possibility>って書き方もアリだと、コードを読む人たちは混乱しませんか?
Won't allowing <new possibility> confuse people reading code?

たとえば (a i) は、関数の呼び出しかもしれないし、配列の参照かもしれない。
E.g. (a i) could be a function call or an array reference.

言語を簡潔にするなら、ある記述で表現可能な意味を増やさざるを得ない。たとえばLispでは関数もデータ型だから、Lispの初心者は「変数xが機能なのか整数なのかわからない」と文句を言うかもしれない。言語を強力にするなら、これは仕方がない。読む人を混乱させずに書けるかどうかは、常に言えることだが、プログラマ次第だろう。
If you make a language terser, you necessarily have more possibilities for what an expression might mean. For example, because functions are a data type in Lisp, someone new to Lisp might complain that he can't tell whether a parameter x is a function or an integer. This is an inevitable consequence of making a language more powerful. It is up to the programmer (as it always is) to avoid using the language in a way that confuses readers.


ArcをJavaやParrotや.NET上に作らなかったのはなぜですか?
Why not build Arc on top of Java/Parrot/.NET?

私たちはArcを長い間、たとえば100年間、みんなに使われるものにしたい。馬鹿げていると思うなら、私たちはそろそろ50歳になることを思い出してほしい。だから (a) 100年間、存続するものを作るときに、近道してラクをしようとは思わない。時間はたっぷりあるんだ。それに (b) すぐに消えるものに固執したくない。でないとプロジェクト全体が、二種類の金属を合わせた板のように歪んでしまうだろう。
We're trying to make something for the long term in Arc, something that will be useful to people in, say, 100 years. (If that sounds crazy, remember that we're already up to 50.) So (a) we're not in a hurry to save effort; when you're trying to make something that will last 100 years, there is plenty of time to work on it, and (b) we don't want to adhere to anything that isn't timeless, lest the whole project curl up like a bimetallic strip.