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.
But I could just write 'arc' for Java, and the above example would fall out.
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.
One language feature that's used here is lexical closures. This would be hard to implement concisely in a language without them.
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.
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: https://qht.co/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.
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.