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

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?

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

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)

A language which is hard to parse for a computer is often hard to parse for a human. For instance, computers have fewer problems with the amount of short-term context memory. 'Magic' is often considered bad because it's inexplicable, while clarity is a principal virtue of a programming language in the eyes of many.

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

"A language which is hard to parse for a computer is often hard to parse for a human."

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.

"LISP is by definition the best programming language"

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 :)

There was no claim that a language that is easy to parse for a computer is always easy to parse for a human. And you don't present any data that easier to parse for the human makes it better other than that you like it.

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.

> Sorry if it wasn't clear, I was comparing easy parsing to developer happiness.

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.

Maybe it'd be better to think about this as a list of priorities, where there has to be ordinality. For example, developer happiness is the first priority, and ease of parsing falls somewhere further down. When Matz was creating the language, when he came across a problem with multiple solutions, he picked the one that would result in highest developer happiness, not which one is easier for the parser.

Is that a better way of wording it?

I believe we understand the dichotomy you're trying to point out, and calling it a false one.

It is possible (and often correlated) to maximize developer happiness with an easy to parse syntax.

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

Also C, Java, really just about every language in common usage.

Not sure about C, but definitely not true for Java. Or C#. Or Python. Or Pascal.

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.

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