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`…
Ruby Demystified: and vs. &&
31–40 of 74 posts
Re: Ruby Demystified: and vs. &&
#32Not 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`…
Re: Ruby Demystified: and vs. &&
#33It 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.
Re: Ruby Demystified: and vs. &&
#34Not 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`…
Re: Ruby Demystified: and vs. &&
#35> 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…
(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 'false'.Re: Ruby Demystified: and vs. &&
#36Re: Ruby Demystified: and vs. &&
#37Not 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`…
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 something along those lines.Re: Ruby Demystified: and vs. &&
#38Earlier quoted context omitted.
So why have both?
Read the article.
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.
Re: Ruby Demystified: and vs. &&
#39Not 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`…
The problem is that "just like English" does not always translate to "intuitive for a programming language". Programmers don't have a problem with learning a new set of rules that don't work the same as their native language, because programming isn't (and shouldn't be) like writing a letter to your computer.
The simple rule is "if it's a binary operator, it has higher precedence than assignment". That rule works for almost every binary operator in almost every language. Show me an exception (like the comma operator in C), and I'll show you an operator that confuses the hell out of most programmers.
Re: Ruby Demystified: and vs. &&
#40Not 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`…