<ahref="http://blog.livedoor.jp/simoom634/archives/50189369.html"onclick="__gaTracker('send', 'event', 'outbound-article', 'http://blog.livedoor.jp/simoom634/archives/50189369.html', 'simoom’s nest:”The Age of the Essays”の翻訳');"target="_blank">simoom’s nest:”The Age of the Essays”の翻訳</a>
</li>
<li>
<ahref="http://blog.livedoor.jp/simoom634/archives/50642854.html"onclick="__gaTracker('send', 'event', 'outbound-article', 'http://blog.livedoor.jp/simoom634/archives/50642854.html', 'simoom’s nest:ベンチャービジネスのためのアイディア(”Ideas for Startups”の翻訳)');"target="_blank">simoom’s nest:ベンチャービジネスのためのアイディア(”Ideas for Startups”の翻訳)</a>
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.
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.
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.
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.
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.
</p>
<p>
その告知は酷に聞こえるということはわかっているけど、オープンにすることと天秤にかけられているものは多い。昨年の夏に私は Guido van Rossum のPythonについての講演に出かけて、そして彼は前年のほとんどの時間を文字列の表現をある形式から別な形式に変えることに費やしていた。なんで Guido はそうしなければならなかったのか？それは、彼が互換性について考えなければならなかったからだ。しかしそれでも、すでにあるコードをダメにすることを心配するのは好意的に思えるかもしれない。けれど結局はコストがかかる: 互換性について考えることは、一年かけて言語をもっと強力にする代わりに文字セットについて対処することを意味しているんだ。
</p>
<p>
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 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.
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.
I was wrong. Those are the advantages of using lists to represent points.
</p>
<p>
私は間違えていた。それが座標を表すためにリストを使う利点なのだ。
</p>
<p>
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.
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.
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.
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.
