Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ruby Demystified: and vs. &&

blog.tinfoilsecurity.com

Post reply on HN
Print view View original

51–60 of 74 posts

Re: Ruby Demystified: and vs. &&

#51

Post by tikhonj »

lmm wrote: post #35
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…

I dislike using symbols, I think because they draw a mostly-arbitrary line between operators and method calls. As a scala/python fan I like to blur that line, and write code that reads as close to English as possible, so I'd write expressions like (user isActive) and (user.expiry before now) and I think that really is more readable than '&&', in a way that your example obscures because you're still using '>' and 'fal…

In a well-designed, flexible language (which includes Scala), operators are not a special case. In fact, in Scala, they are just methods, so there's no arbitrary line between the two!

I personally like the Haskell/OCaml approach of having operators just be normal functions that happen to be parsed in infix position. It's simple, elegant, uniform and flexible.

Either way, the core idea is that operators should be nothing special.

Re: Ruby Demystified: and vs. &&

#53

Post by Smudge »

meepmorp wrote: post #38
Smudge wrote: post #26

Earlier quoted context omitted.

Read the article.

I did. And I still don't see why you'd have both. 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.

> 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`.

Re: Ruby Demystified: and vs. &&

#54

Post by ch0wn »

eCa wrote: post #48
ch0wn wrote: post #30

Earlier quoted context omitted.

Whether right or wrong, I personally prefer the Python way and I'm not a particular fan of Tim Toady. Especially when working in teams, it's simply easier if you don't have to make up rules, but it's clear upfront what to use, because there is no need for discussion.

This is not really a Tim Toady. && and and has different use cases. One (ruby/perl: &&, python: and) is used to evaluate truthness of two expressions. The other (ruby/perl: and, python: N/A) is more of a program flow operator. Now that I think about it.. If it is a Tim Toady, it is more of _if_ vs _and_ rather than _&&_ vs _and_.

Good point, I haven't thought about it that way.

Re: Ruby Demystified: and vs. &&

#55

Post by [deleted] »

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…

[deleted]

Re: Ruby Demystified: and vs. &&

#56

Post by pcwalton »

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).

> 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).

I think it's just an issue of precedence. Assignment evaluates to an expression in all Lisps, ML, Haskell, Scala, and Rust, without this issue.

Stricter typing can also solve the problem. If assignment evaluates to unit, as it does in ML/Haskell/Scala/Rust to name a few, then the attempt to perform the logical-and operation with unit and bool would throw (in a dynamically typed language) or won't compile (in a statically typed language).

Re: Ruby Demystified: and vs. &&

#57

Post by danso »

tinco wrote: post #41
danso wrote: post #16

Earlier quoted context omitted.

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 o…

Hmm you're absolutely right. I guess I'm projecting, I just read that as using `and` and `or` in places that seemed logical to him, but the paragraph is quite clear in that he just replaced all instances of the symbols with the words. Since that is the case, I fully agree with you and shouldn't have been so snarky. I apologize :(

Well, it's a Friday afternoon :) You were right I didn't read to the very end (I kind of guessed what the OP was going to conclude)...I was mostly interested in seeing of other people thought 'and' and 'or' were good Ruby idioms to use (ignoring the precedence confusion).

Re: Ruby Demystified: and vs. &&

#58

Post by kyllo »

tikhonj wrote: post #51
lmm wrote: post #35

Earlier quoted context omitted.

I dislike using symbols, I think because they draw a mostly-arbitrary line between operators and method calls. As a scala/python fan I like to blur that line, and write code that reads as close to English as possible, so I'd write expressions like (user isActive) and (user.expiry before now) and I think that really is more readable than '&&', in a way that your example obscures because you're still using '>' and 'fal…

In a well-designed, flexible language (which includes Scala), operators are not a special case. In fact, in Scala, they are just methods, so there's no arbitrary line between the two! I personally like the Haskell/OCaml approach of having operators just be normal functions that happen to be parsed in infix position. It's simple, elegant, uniform and flexible. Either way, the core idea is that operators should be noth…

And Lisp takes this idea one step further by having operators just be normal functions that are in the prefix position like normal functions. This, combined with the explicit parentheses to denote evaluation, mean that operator precedence is not even an issue in Lisp.

Re: Ruby Demystified: and vs. &&

#59

Post by sabat »

InAnEmergency wrote: post #33

I think I may be the last person who still thinks "and/or" are just fine for boolean expressions in Ruby. It is true that "and/or" are not equivalent to "&&/||". But I don't find any of the arguments that we should then avoid "and/or" in favor of "&&/||" convincing.

Yup. They're like any other tool. If you're not sure how to use and/or, then don't use them. Or, better yet, study up. Programming can benefit from nuance.
Post reply on HN