Hacker News Reader

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

View on HN

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.

Reply on news.ycombinator.com