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.
In reply to Re^4: Take the Arc Challenge
by mr_mischief
in thread Take the Arc Challenge
by kyle
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |