Ruby has a stated design goal of making developers happy. As far as I'm aware, it hasn't been designed to be easily parsed.
I, as an end user (i.e. programmer), prefer it this way. If ease of parsing is important for you, maybe you should use something like LISP.
That does not mean they're opposite goals. Having parsing ambiguities means insufficient thought has been given to parsing, or the language has been defined as "as implemented" with an ad-hoc and organically grown parser (other examples of such case: Perl, PHP)
> I, as an end user (i.e. programmer), prefer it this way.
You prefer that languages have broken, inane or completely missing grammars? So you like PHP even more than Ruby?
Of course they're not opposite, but you have to choose what to focus on.
> You prefer that languages have broken, inane or completely missing grammars? So you like PHP even more than Ruby?
Sorry if it wasn't clear, I was comparing easy parsing to developer happiness. That is, I prefer a language tries to make me happy rather than be easy to parse. (this goes back to your point above)
This is the key problem with DWIM interfaces in general. When it does what you mean, it's so nice. But sometimes you're stuck with ambiguity and lack of a precise means of expression; then you have to jump through hoops to push the 'intuitive' thing out of your way. (Curiously, both MS Word and Perl, of all things, manifest this problem.)
Whether it often is the case isn't relevant. It may be possible, or even necessary, to make a language hard to parse in order to make it better for the programmer.
Otherwise, by your logic LISP is by definition the best programming language. That maybe be true, but I'm not sure if you would follow your own logic to it's logical conclusion.
Well, that's exactly right, it is the best! Not sure for the GP but I would follow this logic to this conclusion happily :)
Um, er... Sorry, I just recently wrote my first program in Lisp (in Racket exactly) that was something more than a few tens of lines of code and am very happy because of this and I couldn't resist posting this here :)
I like Ruby too, it's actually my favorite language because it's so easy to do metaprogramming, but sometimes I wish it were clearer what the execution will be even if that comes at the expense of some clarity elsewhere.
The problem is that this is a statement which does not make sense. You can have both. And as nine_k notes, a language which can also be harder to read: an ambiguous syntax is also ambiguous for a human reader.
Is that a better way of wording it?
It is possible (and often correlated) to maximize developer happiness with an easy to parse syntax.
Also C, Java, really just about every language in common usage.
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...
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 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.
(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));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.
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.