This is also a terrible idea because of the mindless focus on removing characters that it encourages. Look at this quote from the Catalyst one: "...work's underway to tersen up the syntax." Please don't! The syntax is totally unreadable already.

I think the challenge needs to be viewed in the context of what Paul Graham considers Arc to be. He calls it a medium for sketching software and says it's an exploratory programming tool.

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 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?

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.

For example, this is short and clear (to me, anyway):

one: form two, text foo
two: link three, "click here"
three: say "you said: " . foo
[download]

Arc itself may not be exactly mainstream yet, but as a Lisp dialect it's familiar enough to a wide enough audience. It's certainly reasonable to expect that the challenge specifies popular languages, and could have also specified that the languages be general-purpose.

And they say perl is obfuscated!!! I liked almost every other example in that thread far better, what good does concise do if you have to learn a whole knew language to read it? I don't program Python or Ruby but the examples in those languages should make sense to any programmer. Below is my perl code, i think its easier to read, easier to expand, and easier to understand than the arc example. The only thing is it isn't shorter! Should I re-write it in a compact form like his? That seems insane.

#!/usr/bin/perl
use strict;
use warnings;

use CGI;
use CGI::Session;

my $cgi     = new CGI;
my $session = new CGI::Session();

print $session->header();

$session->param('name', $cgi->param('name')) if ($cgi->param("name"));
$session->clear('name')                     if ($cgi->param("c"));

if ($cgi->param("m") eq 'show') {
        print "You said:", $session->param("name"), " ", $cgi->a({href
+=>'?c=1'},'Start Over');
} elsif ($session->param("name")) {
        print $cgi->a({href=>'?m=show'},'See what you said');

} else {
        print $cgi->startform, $cgi->textfield('name'), $cgi->submit('
+Submit'), $cgi->endform;
}
[download]

what good does concise do if you have to learn a whole knew language to read it?

Are you suggesting that nothing is worth anything if you have to learn a whole new language? Or just brevity?

Arc is actually pretty easy to read if you know Lisp.

"What should it profit a man, if he should win a flame war, yet lose his cool?"

I don't think it is worth learning a whole new language just for brevity, I think in the end more time will be spent learning all those strange shortcuts than is saved by how short it is. I wonder if a regular Lisp program would be easier to read or if my confusion more centered around Lisp than Arc.

If you consider that pretty easy to read then could you explain the example to me? Because I have no idea where its saving stuff in a sessions, where its generating HTML, whats responding to each HTML request, etc. I've never learned lisp and maybe thats the problem.


___________
Eric Hodges

  .
[download]

Of all the bitter / negative responses, that is by far the funniest.

(btw - I had some trouble getting that to run on my machine - perhaps you have a syntax error somewhere in there? The compiler says it's on line 1..)

Unlike Mr. Graham's toy language, mine is Unicode-compliant. That's one of the many confusingly visually identical dots.

Maybe you could get that standardized as a feature extension to HQ9+.