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

41–50 of 74 posts

Re: Ruby Demystified: and vs. &&

#41

Post by tinco »

danso wrote: post #16
tinco wrote: post #11

Earlier quoted context omitted.

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 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 :(

Re: Ruby Demystified: and vs. &&

#42

Post by knotty66 »

caw wrote: post #5
danielweber wrote: post #4

Seeing "and" or "or" in Ruby code now leaps out at me with danger signs. I've decided it's just not worth it.

I've never actually seen "and" or "or" in Ruby code. I very frequently see it in Perl code.

I see it fairly often in Rails controllers, e.g.

render :action => "some_action" and return

Re: Ruby Demystified: and vs. &&

#43

Post by thedufer »

pyre wrote: post #8

This is basically the author finding out something in Ruby that was copied from Perl. E.g. it allows one to do: $fh = open() or die("File did not open") Instead of: $fh = open() die("File did not open") unless $fh

What's wrong with

    $fh = open() || die("File did not open")
? The only difference is that the results of `die` are assigned to `$fh`, but I don't think `die` even returns. It still short-circuits.

Re: Ruby Demystified: and vs. &&

#44

Post by RegEx »

nsmartt wrote: post #29
trebor wrote: post #3

Earlier quoted context omitted.

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

To avoid a potentially useful language feature because you might make a mistake with it is, to me, a absurd. A much better argument might be Use only when you fully grasp its use , which is true of any feature. Some are more difficult to understand than others, especially when trying to relate a feature to another language, but that's just not an argument I can support.

It might not just be you working. Sure, use things that you understand. The problem comes when you aren't even aware you don't understand due to subtleties you may have not encountered yet. Then you do some debugging, do some googling, and bam, now it's "obvious to anyone with half a brain, everyone should just RTFM"

Re: Ruby Demystified: and vs. &&

#45

Post by pacaro »

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.

It seems to me that Ruby's "and" and "or" are more similar to Prolog's ','/2 and ';'/2

([Edit] not that Prolog is necessary a shining example of a mainstream programming language)

Re: Ruby Demystified: and vs. &&

#46

Post by tinco »

goatslacker wrote: post #40
tinco wrote: post #14

Earlier quoted context omitted.

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

This explanation is an excellent way to teach and vs &&.

I don't think it actually works as a good explanation of the differences, the article it self does a good job by explaining the precedence rules which is the actual technical difference between the two. My explanation just shows the intuitive difference.

Re: Ruby Demystified: and vs. &&

#47

Post by georgemcbay »

jfb wrote: post #25
cheald wrote: post #19

Earlier quoted context omitted.

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

Yep. There's no right answer. I say, a pox on both their houses. (and predicate-1? predicate-2?)

As someone currently dealing with a lot of Java code, I love that Java only has && and not "and", it allows Java programmers to construct simple, easy-to-understand constructs like this:

  if (true && false == true) {
     return new BooleanFactory(true);
  } else {
     return new BooleanFactory(false);
  }

Re: Ruby Demystified: and vs. &&

#48

Post by eCa »

ch0wn wrote: post #30
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).

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

Re: Ruby Demystified: and vs. &&

#50

Post by InAnEmergency »

aardvark179 wrote: post #34
tinco wrote: post #14

Earlier quoted context omitted.

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

Both && and and are short-circuiting operators in Ruby. To eagerly evaluate both operator arguments you would need to use &.

"&" isn't even the same category, since it is a definable method and its meaning varies with the value on the left hand side.
Post reply on HN