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

61–70 of 74 posts

Re: Ruby Demystified: and vs. &&

#61

Post by meepmorp »

Smudge wrote: post #53
meepmorp wrote: post #38

Earlier quoted context omitted.

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

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

Re: Ruby Demystified: and vs. &&

#62

Post by nsmartt »

RegEx wrote: post #44
nsmartt wrote: post #29

Earlier quoted context omitted.

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"

I understand the potential harm when working with teams, but I also recognize that it's a shame to limit your use of the language to avoid potential trouble. Surely there's some middle ground to be found over dogma such as Never use .

I'm not suggesting that everyone should understand every detail of every potentially misunderstood feature. I'm suggesting that these situations should be dealt with on a case-by-case basis.

Re: Ruby Demystified: and vs. &&

#64

Post by Smudge »

meepmorp wrote: post #61
Smudge wrote: post #53

Earlier quoted context omitted.

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

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

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.

Re: Ruby Demystified: and vs. &&

#65

Post by NateDad »

meepmorp wrote: post #61
Smudge wrote: post #53

Earlier quoted context omitted.

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

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

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

Re: Ruby Demystified: and vs. &&

#66

Post by Smudge »

NateDad wrote: post #65
meepmorp wrote: post #61

Earlier quoted context omitted.

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

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

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

Re: Ruby Demystified: and vs. &&

#67

Post by lmm »

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…

Yes, that's exactly my point. You wouldn't use symbols for the names of normal functions (at least I hope you wouldn't).

Re: Ruby Demystified: and vs. &&

#68

Post by pyre »

thedufer wrote: post #43
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.

Maybe not in this specific instance, but both operators have different behaviour and different uses.

Re: Ruby Demystified: and vs. &&

#69

Post by pyre »

tinco wrote: post #14
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`…

  | In this way it mimics the way we build sentences,
  | that's smart. That's intuitive. That's Ruby.
That's also a nod to Perl. :P

Re: Ruby Demystified: and vs. &&

#70

Post by InAnEmergency »

jabagonuts wrote: post #37
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`…

"which evaluates its left child, _and_ when it is true returns the value of its right child" I like the way you put that. I always stumble for a moment when asked to explain why using "and" and "&&" interchangeably is not a good idea because it can lead to subtle bugs in your program. Maybe a mnemonic would help to remember this more easily. left && right is true or false, but left and right is right when true or som…

That seems more confusing, since they evaluate to the same thing.

    1.9.3p392 :001 > true && 1
     => 1 
    1.9.3p392 :002 > true and 1
     => 1 
    1.9.3p392 :003 > false && 1
     => false 
    1.9.3p392 :004 > false and 1
     => false 
    1.9.3p392 :005 > nil && 1
     => nil 
    1.9.3p392 :006 > nil and 1
     => nil
Which is why explicitly checking for "true" or "false" in a conditional is unusual.
Post reply on HN