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.