Re^3: Take the Arc Challenge

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?

Comment on Re^3: Take the Arc Challenge

Replies are listed 'Best First'.
Re^4: Take the Arc Challenge by mr_mischief (Monsignor) on Feb 11, 2008 at 18:10 UTC
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.	[reply]

Replies are listed 'Best First'.

Re^4: Take the Arc Challenge
by mr_mischief (Monsignor) on Feb 11, 2008 at 18:10 UTC

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.

[reply]