Why Ruby has so many redundancies?

Question

I love Ruby, for past couple of years it is my language of choice.

But even since I started learning it, I was repelled with the fact that so often there are several ways to do the same (or equivalent) thing. I'll give couple of examples:

• methods often have aliases, so you always have to bother to choose the most adequate, popular or commonly accepted alternative
• and and or, besides && and || - just look at how much confusion precedence difference among them causes
• for keyword, used almost exclusively by inexperienced non-native Ruby developers

What was the rationale behind such design decisions? Did they (Matz?) believe that the language will be easier to adopt, and therefore more popular that way?

Answer 1

When Matz wrote Ruby, he tried to follow the 'Principle of Least Surprise'. Often this meant that there'd be more than one way to do the same thing, for example assigning to arrays by using square brackets, or an insert method. I enjoy it, because I find that rather than trying to remember which exact name to use in which situation (I always used to pause for a moment for size vs length in Java), I just just write what seems logical, and usually it will work. When reading the code, it's normally not a problem to use a different name, as the names are usually self-explanatory. So, I don't worry about which is most adequate or popular, I choose the most logical at the time.

Matz was also inspired by Perl, which has 'There's more than one way to do it' as its slogan.

I don't believe Matz was worried about what would be most popular, he just wanted to write the language he wanted to use.

I'm not going to try to explain and vs && though...

Answer 2

Ruby is inspired by Perl, and one important Perl philosophy is "There is more than one way to do it", i.e. redunancies are fine since they give the programmer more freedom (and increases the odds that the functionality they want is available under the name they'd give it - not only under one). Your decision whether that's actually a good thing.

Answer 3

Beware that and vs. &&, though similar, have different precedence.
a = b && c # => equivalent to a = (b and c). a is set to a boolean.
a = b and c # => equivalent to (a = b) and c. a is set to b, and expression is a boolean.

There's more than one way to do it, but there may be subtle differences between them. (update, just noticed you mentioned the precedence difference in your question... sorry. nothing to see here. move along.)