I'm not even sure if you're serious at this point, but the important distinction here is that the hypothetical library function you created to make this work in Java is (like the even shorter version proposed here: http://news.ycombinator.com/item?id=1005199) not one that anyone ever would put in a library. Its only function is this one case. Whereas the Arc version is built by combining highly orthogonal components that can be recombined to solve completely different problems. Do you really not see the difference?
Its only function is this one case. Whereas the Arc version is built by combining highly orthogonal components that can be recombined to solve completely different problems. Do you really not see the difference?
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.
