But isn't Arc a library written specifically to win this contest?
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.
No, actually. The Arc libraries were written to make general-purpose web apps. I didn't propose the challenge till after the first version of Arc was released. And the way I chose the problem was to think of the simplest stateful web app I could. If this isn't the hello world of stateful web apps, what is?
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).
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.
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?
Comments
But isn't Arc a library written specifically to win this contest?
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.
No, actually. The Arc libraries were written to make general-purpose web apps. I didn't propose the challenge till after the first version of Arc was released. And the way I chose the problem was to think of the simplest stateful web app I could. If this isn't the hello world of stateful web apps, what is?
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?
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).
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.
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?