It seems like a landmine for someone learning the language and a place for bugs to creep in to code.
Pick one and go with it. The extra expressiveness or whatever a ruby person would call it, that comes from the alternate forms just doesn't seem worth it.
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`.
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.
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.