He goes on to say that exploratory programming is a good place for terseness and quick-and-dirty approaches to encapsulation and other language features. He says this is in clear contrast to large-scale programming by large teams.

Given the specific goals of making an application quicker to rough in, run, and edit I can see why there's so much focus on brevity. When you're just looking for a skeleton and a little bit of guts, you don't always want to mess with the skin and clothing.

I can agree that you want a brief and plastic language for exploratory programming. I wonder, though, what happens when it's time for the garage project to move to the data center. I'm guessing that one would have to migrate code out of Arc into a language with more features. So I wonder which is faster...

1. Write quickly in Arc, rewrite in a better language later.
2. Write more slowly in a better language to begin with.

That's if I accept the premise that exploration in Arc would be faster than exploration elsewhere. I tend to think that any benefits in Arc could be put into (or found in) something on CPAN, and I wouldn't need to learn another language.

It may be that the exploration, done quickly in Arc, would take too long in a mature language. In that case, I think the programmer still has to be mindful of when the project has reached Arc's limits and needs to move on.

I think in the specific case of Paul Graham and his biggest fans/followers, one would go from Arc to Scheme or Common Lisp. Neither would be a big leap, and Arc is in fact implemented over MzScheme using many of its facilities directly.

I'd think of prototyping in Arc for another Lisp dialect much as I'd think of prototyping in Perl with small, dirty, somewhat slower pure Perl modules to rewrite later to clean, modular, fast XS-based modules. It's much the same language and easy to move from one to another, but you're looking at exploiting different sets of strengths at different times. I might also compare it to prototyping in Perl 5 with Moose or prototyping under Pugs for programs meant to be targeted later to native Perl 6.

I think the exploratory programming idea itself fits some programmers better than others. A proof of concept or quick prototype can be very useful to try design ideas and figure out what functions go where. Fitting the whole application together the "right" way can take a few tries for some people. If you already know exactly how your application will fit together and only have to implement it, then exploratory programming would probably be a waste of time.

I agree with Paul Graham that terseness is, in general, a good thing, and that quick-and-dirty options are useful in exploratory programming. Both of these are reasons I use Perl, after all.

However, I don't quite see what a golfing challenge proves. Golfing is not about getting code working quickly, it's about wasting hours trying to make your program that one little bit more concise. But in exploratory programming, the key question is not "how concise is my program?", but "how long did it take to get it working?" (closely followed by "can I actually remember what that clever bit does?")

Which raises the question: is the Arc program Mr Graham provides really a typical example of what an average programmer using Arc might naturally produce during an exploratory session, or is it golfed?

You make an excellent point about the natural solution vs. golfing the solution, but I'm not sure Paul Graham is interested in what the average programmer does or does not do. He's looking for something that allows a Lisp programmer to explore a problem faster. These are people who are already expected by their community to be adept at using code to generate and alter code, which would seem to me to be one of the biggest time-savers in the first place.

When you say "average programmer using Arc", I guess I need to be clearer whether you mean an "average programmer" who is "using Arc" vs. "an average Arc programmer" in order to really understand what you're asking. Then, since I have no idea what an average Arc programmer does, I'd still be unable to point you to an answer that someone who has more clue on that topic has provided. From what little experience I have playing with Lisp-based languages, it looks like a natural solution given the right macro or function defs in the library.

My guess is, given that PG was one of the language architects, that the given challenge is his first shot at the problem using his own language and that he didn't golf it at all. I also guess that his challenge for a short yet meaningful program is one of the shortest meaningful programs he could think of in his particular language. If we picked one of the shortest meaningful programs possible in Perl given the standard modules with which to develop it, an Arc program implementing the same thing may well be longer and more convoluted. The whole challenge is against a particular program implementation in his language which shows off its strengths and not necessarily its weaknesses.

I'd be interested to see the Arc implementation of all the stuff on The Language Shootout and also the 99 Problems in (Prolog|Lisp|Haskell|Perl 6). It'd also be nice to see Perl 5 and Perl 6 solutions for all of those exercises, though. The style, length, legibility, coding speed, and running speed of all languages are a big mess of trade-offs considered (hopefully carefully) by every language designer, and vary widely among programmers using any one language. I'm sure Arc is no different, but failing to be better in every case is not cause for deriding the language, its creators, its users, or its proponents. Arc looks interesting, and for some programmers on some tasks it might be the best tool. Any language that can improve the life, career, or even the mood of a handful of programmers part of the time deserves some respect. Arc probably won't replace anything altogether, but it might replace some other version of Lisp as the tool of choice in the toolboxes of a number of programmers.

Perl's famous for making itself a good option among many options. We shouldn't give the Arc folks a hard time for trying to do the same. We certainly can't say our community hasn't had everything from valid and objective demonstrations of the power of Perl down to flat-out pissing contests against shell, sed, awk, Python, Ruby, Java, JavaScript, C, Rexx, and more. Some of these come as challenges from outside the Perl community, and some come from within. If Arc is especially good at this one problem, then good for the Arc folks. Our community, as a whole, would do nothing more high-minded than to show off the strengths of both the language and the community specifically where we have them. Even those willing to openly admit weaknesses are rarely slow to admit strengths.

This is also a terrible idea because of the mindless focus on removing characters that it encourages.

It's not obvious from my node or even from the things I link, but elsewhere it's clear that the focus is not on characters.

The most meaningful test of the length of a program is not lines or characters but the size of the codetree-- the tree you'd need to represent the source. The Arc example has a codetree of 23 nodes: 15 leaves/tokens + 8 interior nodes.