Take the arc challenge

Take The Arc Challenge

February 2008

Arc’s been out for a few days now. Everyone seems to have an opinion about it. The low end are much the same as the low end of opinions about anything online. There’s no high end yet, because no one has had enough time yet to be able to speak from experience about what it’s like to program in Arc. Those are the responses I’m really interested in. But in the meantime, we have the medium-level responses: the opinions of people who have some understanding of the issues involved, but who are writing based on first impressions.

I’ve noticed a strange pattern in these. The main fault they find with Arc is that I don’t seem to have had to work hard enough writing it. Ron Garret writes:
And that is my main gripe about Arc: it has been so long in the making and set such lofty goals and then it seems to pretty much punt on all the hard problems of language design.
I don’t usually refute criticisms directly. Refutations tend to be more gratifying to write than to read. But in this case I’m going to, because in this case Ron & Co are mistaken in an illuminating way. Explaining why will clarify some important issues about language design.

Ron’s right. I didn’t decide what problems to work on based on how hard they were. Instead I used what might seem a rather mundane test: I worked on things that would make programs shorter.

Why would I do that? Because making programs short is what high level languages are for. It may not be 100% accurate to say the power of a programming language is in inverse proportion to the length of programs written in it, but it’s damned close. Imagine how preposterous it would sound if someone said “The program is 10 lines of code in your language and 50 in my language, but my language is more powerful.” You’d be thinking: what does he mean by power, then?

I’m not claiming

that power is the only criterion by which to judge programming languages. It would also be a legitimate goal, for example, to design a language to be easy for kids to learn, or to compile efficiently (though this is less common than it used to be), or to limit the damage that can be done by individual bad programmers within a group. But power is the test of languages not designed for such special purposes.

So working on what makes programs short rather than what’s hard to implement translates to:
I chose what to work on based on the value to the user, rather than the cost to me.
Surely this is the right order of priorities to have in designing not just programming languages, but anything meant to be used by other people.

This is not to say none of the stuff I did was hard. Some of it seemed hard to me. But in language design, solving problems, whether hard or easy, is not the goal. Making a good language is. The real test of Arc – and any other general-purpose high level language – is not whether it contains feature x or solves problem y, but how long programs are in it.

The programs that get shorter should be the ones users actually need to write. So my m. o. while working on Arc was to write applications in it, then comb through them line by line trying to imagine language features that would make them shorter. Then I’d implement those features, rewrite the program to use them, and start over. Here’s a comment from the source of Hacker News where I occasionally kept track:
; results of (codetree “news. arc”):
; 8787, 8760, 8738, 8726, 8823, 8755, 8703, 8628, 8587, 8565
; 8633, 8573, 8552, 8520, 8510, 8498, 8549, 8515, 8684, 9025
; 9573, 12196, 12469, 12648, 12373