Hacker News Reader

Comment by masklinn | Hacker News Reader

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

View on HN

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

Reply on news.ycombinator.com