[Smudge]

> Pick one and go with it.

They did. It's `&&` and `||`.

I understand your point when it comes to it being a potential landmine, and honestly I never use them myself. But I've never seen any ruby guides or docs use `and` instead of `&&`, and I have seen skilled rubyists make great (and correct) use of `and`.

[meepmorp]

> They did. It's `&&` and `||`.

I assume you mean idiomatically chosen, since clearly the decision wasn't made at the language level.

> I have seen skilled rubyists make great (and correct) use of `and`.

I'm obviously not a ruby programmer, so it doesn't matter much to me, but it seems odd to argue that having a largely disused second set of logical operators in a language that skilled people periodically trot out for some cases is anything but a design wart. Maybe it's a cultural thing in the ruby world.

And, honestly, I don't mean that to sound snide or slighting. It's just odd to me.

[Smudge]

Fair point. It is a bit odd. IIUC the low/reverse-precedence operators came from Perl, and whether or not to use them is just a stylistic choice. It's clear what this means:

> raise "ooops" unless do_something()

But even so, it reads a bit backwards. Some codebases do this instead:

> do_something() or raise "oops"

That's just repeating one of the examples in the article, but it jumps out to me as the one I've seen most often.

[NateDad]

I never understood what Perl (and now Ruby) has against if statements.

  foo or do_something()

is exactly the same as

  if foo {
      do_something()
  }

Except the latter is WAY less likely to be accidentally misread.... and don't even get me started on

  do_something() unless foo

[Smudge]

It's all just a matter of taste and preference. If you find yourself consistently misreading commonplace ruby, maybe ruby isn't for you.