29 January 2008
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 few 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
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.
Which is why, incidentally, Arc
only supports Ascii.
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
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
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
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
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.