A well-balanced "contest" would probably include a bunch of specifics (web, 3d, computation, ...) or stick to generic "programming" ("implement a self-balancing binary tree").

I see the Arc contest as more of something like, "take a look at what happens when you think about a problem space in depth and write a domain-specific language to make solving problems in that space really easy".

The only downside of Arc is that other domains are not as easy to work in. If you design a DSL on top of an existing language, then you don't have that limitation, which is what's good about the Haskell implementation. If I need to write a parser for part of my web app, I can use another nice DSL for that. If I used Arc, I would not have that option.

There's nothing about this problem that's biased towards Arc's strengths. Take input from a form and print it on the next page. Every popular language already had libraries for such basic things.

I suppose Arc was designed to win this contest in the sense that Arc is designed to make programs short, and winning in this contest is measured by brevity. Is that what you meant?

Not really. If I added a condition to the contest that you didn't take into account when writing Arc, Arc would no longer do as well. When the same person designs the programming language and the contest to "prove" it's the best, the contest is likely to prove that his programming language is the best. Not due to malice, but rather because both the language designer and contest designer think exactly the same way (as they are both the same person).

Ok. Now let's explore (or rather, return to) the question of whether that happened in this case.

Since I was aware people would make this type of criticism when I proposed the challenge, I made a conscious effort to make the problem very generic-- in fact to be the simplest stateful web app I could think of. In your opinion, did I succeed? Is it a simple, generic problem to ask for input on one page and display it on the next? Or is this a complex problem that requires unusual, Arc-specific functionality to solve?

Just another vote for 'I have no clue what the point of this is'.

The challenge seems to be:

  * Write a library with helper functions. Like the Arc library.
  * Now you can write a short program that uses that library to do things.

The example in Arc:

  (defop said req
  (aform [onlink "click here" (pr "you said: " (arg _ "foo"))]
    (input "foo") 
    (submit)))

createForm("click here", new Response("you said %foo"), new InputElement("foo"), new SubmitElement());

I think there's more important things to compare in languages. speed, error handling, stability, memory management etc

But I could just write 'arc' for Java, and the above example would fall out.

The solution for arc doesn't have anything unique in it that you can't do in other languages just as concisely.

So I don't think it says anything at all about the language, it just says how well you designed the interface to helper libraries.

>> "all the language features used in the Arc version of the challenge are used throughout news.arc."

I don't see any 'language features' in the solution for Arc. It's just functions and parameters. They're not language features, they're helper libraries. They may be well designed good libraries, but that's what they are. The language used is irrelevant. You could have written arc in BASIC and the solution would be the same.

Maybe I just don't understand why arc is referred to as a 'language' rather than a framework/library, and why that distinction is important.

In terms of language design, if you were to write news.arc for Java, would you expect a solution to the challenge to just fall out? This probably says more about MzScheme+pg vs Java+you than it does about arc, however.

If you wrote an Arc implementation in Java, then ran the program on top of that system, surely that would count as an instance of Arc winning the the challenge, not Java.

This is why the appropriate test is the ability for an average programmer to put together a DSL for a randomly-selected problem domain: it actually speaks to the power of the language. The characteristics of orthogonality and combinatorial flexibility is what DSLs are made to do. Arc doesn't have a monopoly on them. The only thing that is interesting here is your choice to include web-specific functionality in Arc. I think it's a great choice, but it just doesn't say much about the general expressiveness of the language as a whole.

We may have reached the point here where splitting hairs over DSLs versus included libraries is not going to get anybody anywhere. From what I understand, I would certainly agree that Arc programmers having such easy access to stateless web programming in a highly flexible manner is a great thing for the language.

But I would judge any language by the ability to easily add solutions to other problem domains that are highly orthogonal and flexible, not necessarily by the problem domains that are enabled by default.

Hope that makes sense. I think I finally figured out what your point was.

createForm("click here", new Response("you said %foo"), new InputElement("foo"), new SubmitElement());

Does this not look like a combination of highly orthogonal components that could be recombined to solve a variety of problems?

So no, I can't see any different whatsoever. I'm guessing we'll just have to agree to disagree at this point.

You've widened the scope of "language" to its libraries. And that's entirely fair. So, yes, Arc has it "built in", but Arc itself is (IMO) only marginally more mature than the libraries one might invent for (e.g.) Haskell to do the same thing (ok, I'm being a little unfair here, but not that much IMO). And one can invent those libraries for another language and can match Arc in the challenge using those invented libraries -- at least you don't seem to be denying this.

So, then, what's the point? That Arc already has the libraries available? That the Arc libraries meet the challenge? It certainly isn't that those libraries aren't possible in another language. The challenge means (almost) nothing with regards to comparing programming languages as you first implied, and is more about what tools and libraries were invented along with Arc to develop web apps.

Depends on the language, obviously. It seems unlikely you could in C, for example. Presumably the problems you'd encounter would gradually decrease as the language grew more powerful. That's why I phrased the problem as a challenge. I was curious to see what happened when you tried to solve this very simple problem using existing language/library options.

Yes, instead of creating a new library for the challenge you created the challenge to suit the library.

By the way, why did you choose to use string names for the data in the input form? Why not use variables directly and make aform work more like let (and like Mathematica's manipulate):

    (form
       (name (input-string))
       (age (input-number))
       (pr "Hello, " name ". You are " age " years old."))