I've done a lot of java and a lot of ruby. Anyone that states that Java makes them happier as a developer is viewing the world from a very different perspective than I am.

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.

Java is indeed pretty nasty, but I would consider it easier to parse visually than Ruby. Less ambiguity.

I think your definition of "parse visually" is very different than mine. The java version of the below would be much harder to parse visually for me.

https://gist.github.com/jaydonnell/4735159

I really hate this "My language is better than your X" talk. Remember that the reason that you find a language predictable in usage is often because you have experience using it, claiming that it's syntax will be clearer from the start is misleading.

Also, you could have structured the "supreme readable ruby code" much more cleanly:

https://gist.github.com/cronin101/7024c1c0dfa721ec1dab

My point isn't "language x is better than language y". My point is that "unambiguous" syntax can be harder to visually parse than a more ambiguous syntax. Java has a lot of noise that makes it hard to visually follow the intent of the code, even though it is less ambiguous.

Admittedly I could have come up with a better code example :) I wanted to show code transforms a collect a couple of times.

That is because of lack of features, particularly in libraries.

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.

I just want to point out that unambiguous is not the same thing as easy to visually parse. Java often is very nosy which makes it hard to visually see the intent of the code, even if it is unambiguous.

Unlike you, I'll avoid the ad hominem. The commenter I was replying to said that java is EASIER to visually parse. Your java code is harder to visually parse than my ruby code. It's not hard to visually parse, but it's harder than the ruby code which was my point.

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.

My name is J. Chan, and I forgot the password to my other account. Thanks for making fun of my name.

Why didn't you add the sort?

Use a Comparator. http://docs.oracle.com/javase/6/docs/api/java/util/Comparato...

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.

I'm absolutely talking about visual clarity. In the ruby code it is significantly more visually clear what is going on because the java code has a lot of incidental noise. If you would show a java version that would be clear to everyone, which is probably why you didn't add the sort. The code side-by-side will speak for itself.

Wow guys really.

  Iterable<String> s = Splitter.on(" ").split("Hello World");
  Multiset<String> counts = HashMultiSet.create(s);
  Multiset<String> sorted = Multisets.copyHightestCountFirst(counts);

Or to sort by counts directly

  TreeHashSet.create(Splitter.on(" ").split("Hello World"))

Granted this uses guava, but there is nothing really more readable about your ruby code than this guy's java code. To say he 'lacks courage' ... jesus I'm still laughing. "Why didn't you add the sort!" You're too much man.

Your code doesn't do the same thing as mine. You need to start with an array of sentences.

Show the java code that does the same thing and it will be clear that the ruby is more readable.

It will not be clear: You can replace the first line with the following two

  String[] sents = {"the quick", "the slow", "the blue"};
  Iterable<String> s = Splitter.on(" ").split(Joiner.on(" ").join(sents));

Guava is nice, it makes java almost bearable.

That's orthogonal to the point, though - when I write ruby, I don't care about how it will get parsed, I care about how it will run.

This is sort of an odd statement since the way a piece of code is run is directly related to how it is parsed. If an alternative implementation like Topaz parses something differently than MRI then you'll have code that does two different things on two different interpreters. Having a complicated and informally specified grammar makes this a lot harder to avoid.

Ah okay. Cool, thanks!

Python is not context free.

Indentation is handled by the lexer, not the parser.

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.

It is context free. INDENT and OUTDENT are directly equivalent to { and } in other grammars.

The difference is that INDENT and OUTDENT have to be defined by context-sensitive productions. Even if this occurs in what would otherwise be the "lexing" stage of the parser.

And there's no way java is. Not sure about Go.

The Java language specification includes a description of the language as a context free grammar.

That alone does not make it a nice language, of course.

> The Java language specification includes a description of the language as a context free grammar.

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)`.

It can be parsed to an AST -- as you note, it can be parsed into two ASTs. It's called an ambiguous grammar, which can still be context free.

> It can be parsed to an AST -- as you note, it can be parsed into two ASTs.

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...