As a person who works in a commercial environment, where code maintenance is more important than the generation of new code, looking at the above makes me want to never, ever, ever consider Arc for any development.
Writing short programs is nice, but looking at the above example, I can't make heads or tails out of it, or how it works. "Unfamiliarity with Arc's library!" you cry. Yes. Yes it is. But, I'm just as unfamiliar with other frameworks demonstrated in the comments, and I can follow those just fine (well, except the Perl and Ruby ones). The Python examples are _stellar_ in their comprehensibility, with ANSI CL coming in at a close 2nd place, and Smalltalk following in at a luke-warm 3rd place; there is sufficient redundancy in the code that, while being short and sweet, it still gave enough context to know and understand how the pieces fit together.
Not so with Arc. It's TOO terse. This is the same problem that you see with otherwise stellar languages like J/APL, Perl-golf, and older Linux and BSD source code files. Yes, your productivity sky-rockets when you write the code. Alas, your productivity sinks like a rock while trying to maintain it, unless you've been at it for at least 3 years.
This language is not for me. The cost-benefit ratio is not sufficient to make me jump ship.
Really? I could read it just fine, and I've never used Arc before. There was a bit of a learning curve when I was figuring out what the library functions did, but that took about 15 seconds -- roughly the same time it took to figure out exactly what was happening in the Python and CL examples.
Your understanding problem can probably be traced to two things: the implicit separation of the code into different pages (you haven't used the library yet, so you don't know what visual cues to look for), and the backwards order of the pages from the structure of the aform and w/link macros. Both problems can be solved by using Arc's library for an hour or two: you'll either get used to Arc's library or you'll find a way of handling common cases that's more to your taste.
In this case, I suspect the code could be made a lot clearer to you by splitting it into separate page-maker functions for each of the pages that the user will see. This would add about three lines of trivial code, assuming that the library works the way I think it does.
