Python, Haskell, Java, Go have formal and even context-free grammars. It makes me as a developer happy since it's much easier to predict how the language will parse something.
That right there is why I disagree with your point. I'm far happier programming in ruby than java, even though there is more ambiguity to the syntax.
Also, you could have structured the "supreme readable ruby code" much more cleanly:
Admittedly I could have come up with a better code example :) I wanted to show code transforms a collect a couple of times.
While it takes longer to read the Java version, it is unambiguous what it does. With Ruby (as nice as the language is) that is not always the case, at least for me.
(Pardon the tabbing, I don't have that much time to waste on uneducated comments like the above)
btw, I've added a sort to mine, what would that look like for yours?
https://gist.github.com/jaydonnell/4735159
Edit: I see you don't have the courage to use your real account.
Since it seems like you're talking about visual activity now instead of visual clarity, I agree that Java will be more "hard to read" under your definition. But aside from the two lines for the class declaration & method declaration and the other two for the ending brackets, there really isn't much bloat.
All that you have to implement for a simple numerical sort is some logic if a > b return 1 else if a == b return 0 else return -1.
Iterable<String> s = Splitter.on(" ").split("Hello World");
Multiset<String> counts = HashMultiSet.create(s);
Multiset<String> sorted = Multisets.copyHightestCountFirst(counts);
TreeHashSet.create(Splitter.on(" ").split("Hello World"))
Show the java code that does the same thing and it will be clear that the ruby is more readable.
String[] sents = {"the quick", "the slow", "the blue"};
Iterable<String> s = Splitter.on(" ").split(Joiner.on(" ").join(sents));The parser is context free-- LL(1), actually.
The lexer maintains one extra stack to track indentations, meaning it's more of a PDA than a DFA, but the actual complication is mild.
That alone does not make it a nice language, of course.
I can only assume that it's lying its pants off, as I noted in an other subthread `(a) - (b)` can't be parsed (to an AST) without knowing the identity of `a` in the current scope: if it's a type the expression is a cast of `-(b)` to `a`, if it's a value it's a subtraction of `(b)` from `(a)`.
By "it can't be parsed to an AST" I meant "it can't be parsed to a useful AST used to run or generate code" on its own, it needs to be disambiguated through contextual information before anything can be done with the prospective subtree. Sorry for the lack of clarity.
> It's called an ambiguous grammar, which can still be context free.
The only way to disambiguate is to provide expression context (namely visible name bindings at this point), it's essentially the same problem Eli Bendersky described when talking about C grammar's context-sensitivity: http://eli.thegreenplace.net/2007/11/24/the-context-sensitiv...