That said, I must disagree with Paul's recent blog entry/essay and this challenge...

Brevity or compactness as a measure of a language's "greatness" is a red herring. There are two acceptable methods by which source code can be compact: syntactic sugar and factoring/libs. I say "acceptable", because I don't consider putting everything on 1 line or using function names like "f" acceptable. And while syntactic sugar can be good at times, it can also lead to write-only code (see: APL, Perl (imo), and many others).

There's absolutely nothing special with PG's example code and the challenge isn't much of a challenge at all. Analogy: everyone has cars and I "invent" a jet, and then challenged everyone else to a race from Boston to LA. I've picked a challenge to show off what I consider to be my best trait: speed. Why didn't I challenge everyone to get from my home to the local grocery store? Given the terrain, perhaps a mountain bike would have been the best tool for that job.

How about this challenge for Arc:

On a little-endian machine, read in the Quicktime .MOV header atom format (big-endian), parse, and dump it to the console in a human readable format.

The reason I say there's nothing special with the example code is that we all know there's a lot of code going on under the hood behind it - a lot of code that PG has already written. And it's a cop-out to state at the end of the challenge... "Code to import standard libraries doesn't count..."

The code still had to be written. It isn't magical just because it comes standard. It shouldn't make a difference if it's included with the language or downloaded from the internet. The question isn't how much code was written, but rather, how much code did I have to write?

Again compactness is a red herring.

Perhaps Arc will be my language of choice for implementing <insert task>. It would be far more informative to me to be told (by PG) what problem(s) Arc is being design to solve and then show me how my life as a programmer would be easier - using Arc - to accomplish those tasks.

Again, I wish PG all the best with Arc, and I look forward to using it. But currently, I very much agree with Ron Garret when he said, "...[Arc] seems to pretty much punt on all the hard problems of language design."