# Ruby, I love you but you're bringing me down

Ruby is great, I find it super expressive and concise. But sometimes you find corner cases which are very hard to explain. During an interview on the philosophy of Ruby, Matz said:

Sometimes people jot down pseudo-code on paper. If that pseudo-code runs directly on their computers, it’s best, isn’t it?

Yukihiro Matsumoto, creator of Ruby

So clearly it’s important for this language to be readable by humans, I guess that’s the reason why this language isn’t as mathematically strict as many others. It aims to be easily understood and it doesn’t even have a standard specification.

The lack of a spec sometimes makes it impossible to reason about whether something is wrong or intended within the language. And I have one example of this.

Take the following program:

def some_method(x)
x.class
end
a = false
b = 42


Sometimes you hit confusing features but you quickly find a good explanation:

some_method(a || b)    # => Integer (ok, as expected)
some_method a || b     # => Integer (ok)
some_method((a || b))  # => Integer (ok)
some_method a or b     # => FalseClass (ok?)


This may be confusing but makes perfect sense. While you can use both the or operator and the || they’re not exactly the same. The or & and operators have a much lower precedence, so the last call is equivalent to some_method(a) or b. Here’s another blog post by Preston Lee on these operators if you’re very interested. So far Ruby is clear enough.

On the following example, a good explanation isn’t found that easily:

some_method((a or b))  # => 42 (ok)
some_method (a or b)   # => 42 (ok)
some_method(a or b)    # SyntaxError (Hmm)


That’s certainly confusing, there’s no ambiguity in the last line so I would expect its syntax to be as valid as the other two lines.

I really have no idea if this is a bug or expected behavior. It might happen that this isn’t documented or described anywhere and if that’s the case the only person who can answer that question is Matz.

¯\_(ツ)_/¯