Paul, in emphasising code brevity I think you are missing a greater good. I believe most of us subconsciously look for a language that is frictionless -- one that allows us to express our ideas without the language getting in the way. To me this is a far more appropriate measure of a language's power than the length of a program. I'd love a language that would allow me to stay in flow* and express my creativity without having to stop and think about the actual language itself. That would be the ultimate Zen power tool.
To be more specific here are three attributes that seem to aid frictionless flow. (perhaps in order of importance) -
--> Expressiveness -- i.e. simple, explicit and unambiguous abstractions.
--> Obviousness and readability. -- i.e. no need to decipher tokens, and the code structure illuminates the intention and flow of the process.
--> Terse. -- i.e. apart from the obvious benefit of requiring less work it also helps me 'keep the whole program in my head'.
There's nothing wrong with brevity of course, but when pursued for it's own sake it seems to be counter productive, in that when you focus on terseness alone there can be a tendency to ride roughshod over the more important attributes: expressiveness and obviousness. You then end up with code that's not as enjoyable to create and whose beauty is lost, except perhaps initially to it's creator.
BTW Paul, this is a great first shot, so a big thank you. I, for one, am routing for Arc to be a widespread success, if only so I can do most of what I need to do in a language that I really enjoy.
what I see is more or less ordinary lisp that uses a library to solve an issue with applications that rely on http. I'm sure plenty of us could do the equivalent with the appropriate Python/Perl/Php/Ruby library, but then the obvious criticism would be that you're not really comparing lanugages. You would be comparing libraries.
Is it really the case that when you boil it down, Arc (language+libraries) is about making small web programs? If not, why this challenge and if so I suspect it won't live up to the 100-year idea.
One thing I've noticed about languages: you can't really tell which is better from such a short sample.
Paul calls Prolog pattern matching great for writing basic list manipulation functions, then downhill from there. But if you're looking at those kinds of toy problems (how do you write reduce?) you get a biased sample.
Really, you have to try writing something representative of your problem space. And that code snippet is not at all representative of my experience writing web applications; it lacks:
* Persistent storage
* Large pages with multiple possible forms and actions
* Javascript
* Caching
* Complicated queries
* Pagination
In fact, what the demo code amounts to is a 2 step wizard. And in all of Justin.tv, we only have two wizards. So I don't think this is a good test for length of a web app.
One extremely important question: What would be? Is there some kind of canonical example application that could be designed?
I'm not sure I'd use db-transactional-serializable-migratable closures that often even if I had them (assuming the overhead wouldn't be worth the occasional "session timeout" message the user would see). Perhaps in some domains though?
Looking at clients' deployed applications, the web boxes tend to average over a year's uptime so I can't say it seems like it'd matter that much.
Provided you've got runtime code loading and a useful QA process, I don't really see why you'd need to care - MySQL's lack of transactional DDL causes far more downtime than lack of serialisation would were we using a continuation-based system.
