Ruby Demystified: and vs. && • Hacker News Board

Re: Ruby Demystified: and vs. &&

#11

Post by tinco » Fri, Mar 08, 2013, 9:40 PM UTC

danso wrote: post #7

> When I first started learning Ruby, I was excited to discover that Ruby has the keywords and and or as boolean operators. I quickly got into the habit of writing all of my boolean statements with these, instead of the more conventional && and ||, because my code became so much readable pry(main)> a = true && false pry(main)> a = true and false Hmm...I dunno, I don't think the latter is necessarily easier to read th…

This article isn't about replacing symbols with words, ruby isn't about replacing symbols with words either, and there is no place in the article where the author states that

    a = true and false

is prettier than

    a = true && false

And if you would actually have read the article and paid close attention you would have learned that the two lines you just said are not functionally equivalent.

No ruby programmer would ever have a line that says

    a = true and false

It just makes no sense.

Maybe a very experienced ninja ruby programmer would, but that programmer would know exactly what he was doing.

The beauty in ruby and in the 'and' keyword is that a ruby programmer intuitively knows when to use which. This article just clears up why exactly they work like you expect them to work.

edit: maybe a weird programmer would do something like this

  @message = "We failed :(" and false

at the end of a function that has conditionals with return statements in them.

Re: Ruby Demystified: and vs. &&

#12

Post by graywh » Fri, Mar 08, 2013, 9:41 PM UTC

  and and or are control-flow modifiers like if and unless.

http://devblog.avdi.org/2010/08/02/using-and-and-or-in-ruby/

Re: Ruby Demystified: and vs. &&

#13

Post by meepmorp » Fri, Mar 08, 2013, 9:42 PM UTC

trebor wrote: post #3

klochner wrote: post #2

tldr: && has higher operator precedence than "and" Significantly, "&&" > "=" > "and", which can lead to unintended results when refactoring "&&" --> "and"

I.E.: why you should always use && instead of "and".

So why have both?

Re: Ruby Demystified: and vs. &&

#14

Post by tinco » Fri, Mar 08, 2013, 9:47 PM UTC

aston wrote: post #6

Not to start a language war, but this blog post demonstrates two things Python got right that Ruby got wrong. First, in Python, there's only one way to express a boolean "and". The && operator is left out. Second, this post demonstrates a danger of allowing assignment via '=' evaluate to an expression (granted with less weird precedence rules it wouldn't turn out as bad in this case).

Not to acknowledge we are at war, but allow me to react to your act of war.

This article demonstrates one thing that Ruby does awesomely, and python does not at all. Wether that makes Ruby better than Python.. well yes it does, no point in being diplomatic now, we're at war!

In Ruby there is only one way to express a boolean and, it goes: &&. Besides the boolean and there is also a binary operator with the name `and` which evaluates its left child, _and_ when it is true returns the value of its right child.

In this way it mimics the way we build sentences, that's smart. That's intuitive. That's Ruby.

Re: Ruby Demystified: and vs. &&

#15

Post by graywh » Fri, Mar 08, 2013, 9:48 PM UTC

aston wrote: post #6

Not to start a language war, but this blog post demonstrates two things Python got right that Ruby got wrong. First, in Python, there's only one way to express a boolean "and". The && operator is left out. Second, this post demonstrates a danger of allowing assignment via '=' evaluate to an expression (granted with less weird precedence rules it wouldn't turn out as bad in this case).

Python's "and" is equivalent to Ruby's "&&". Python has no equivalent to Ruby's "and" which is copied from Perl. In other words, Ruby has only one way to express a boolean "and", "&&", but the existence of the flow-control modifier "and" trips up new users constantly. Which is why this topic lands on HN regularly.

Re: Ruby Demystified: and vs. &&

#16

Post by danso » Fri, Mar 08, 2013, 9:49 PM UTC

tinco wrote: post #11

danso wrote: post #7

> When I first started learning Ruby, I was excited to discover that Ruby has the keywords and and or as boolean operators. I quickly got into the habit of writing all of my boolean statements with these, instead of the more conventional && and ||, because my code became so much readable pry(main)> a = true && false pry(main)> a = true and false Hmm...I dunno, I don't think the latter is necessarily easier to read th…

This article isn't about replacing symbols with words, ruby isn't about replacing symbols with words either, and there is no place in the article where the author states that a = true and false is prettier than a = true && false And if you would actually have read the article and paid close attention you would have learned that the two lines you just said are not functionally equivalent. No ruby programmer would ever…

Wow, I must have missed the point. Because I could've sworn the OP was talking about how he thought that 'and' and 'or' could be stand-in's for && and ||, but he found out that they aren't quite equivalent. Because if they were equivalent, he would substitute words for symbols because, as I quoted, "[his] code became so much readable."

I'm not evaluating what he discovered at the end of the post. I'm evaluating his original intent for using 'and' and 'or' in the first place, which was readability. I'm simply stating my opinion on that comparison.

And yes, "a = true and false" doesn't make sense. I just copy-pasted his sample code as a quick example. I didn't expect people to take it literally, as if I were showing off a best practice.

Re: Ruby Demystified: and vs. &&

#17

Post by jfb » Fri, Mar 08, 2013, 9:49 PM UTC

graywh wrote: post #15

aston wrote: post #6

Not to start a language war, but this blog post demonstrates two things Python got right that Ruby got wrong. First, in Python, there's only one way to express a boolean "and". The && operator is left out. Second, this post demonstrates a danger of allowing assignment via '=' evaluate to an expression (granted with less weird precedence rules it wouldn't turn out as bad in this case).

Python's "and" is equivalent to Ruby's "&&". Python has no equivalent to Ruby's "and" which is copied from Perl. In other words, Ruby has only one way to express a boolean "and", "&&", but the existence of the flow-control modifier "and" trips up new users constantly. Which is why this topic lands on HN regularly.

Which is, from the Python mindset, a flaw in Ruby the language.

Re: Ruby Demystified: and vs. &&

#18

Post by smsm42 » Fri, Mar 08, 2013, 9:53 PM UTC

eaurouge wrote: post #9

Makes for an interesting blog post, I guess. But precedence for "&&" and "||" in Ruby are similar to precedence for "&&" and "||" in C, Java and others, and they are similar to precedence rules for "and" and "or" in Python. Precedence rules for "and" and "or" in Ruby are an anomaly not just in the Ruby world but in many (most?) mainstream languages.

"In many (most?) mainstream languages" doesn't really agree with "anomaly". If it's in most mainstream languages, then it's not an anomaly, it's the norm.

Re: Ruby Demystified: and vs. &&

#19

Post by cheald » Fri, Mar 08, 2013, 9:54 PM UTC

jfb wrote: post #17

graywh wrote: post #15

Earlier quoted context omitted.

Python's "and" is equivalent to Ruby's "&&". Python has no equivalent to Ruby's "and" which is copied from Perl. In other words, Ruby has only one way to express a boolean "and", "&&", but the existence of the flow-control modifier "and" trips up new users constantly. Which is why this topic lands on HN regularly.

Which is, from the Python mindset, a flaw in Ruby the language.

And from a Ruby mindset, is a limitation in the Python language. :)

Re: Ruby Demystified: and vs. &&

#20

Post by smsm42 » Fri, Mar 08, 2013, 9:54 PM UTC

Operator precedence (and && vs. and with different precedence) has been around since forever - this particular one since Perl was a fresh and novel thing at least. If it's a mystery that needs "demystifying" for somebody, it's time to hit the books.