5 ms·
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 a
by tinco 14y ago
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.
- baddox 14y agoMy biggest complaint is that you called Ruby's way "intuitive."
- deleted 14y ago[deleted]
- aardvark179 14y agoBoth && and and are short-circuiting operators in Ruby. To eagerly evaluate both operator arguments you would need to use &.
- InAnEmergency 14y ago"&" isn't even the same category, since it is a definable method and its meaning varies with the value on the left hand side.
- jabagonuts 14y ago"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 something along those lines.
- InAnEmergency 14y agoThat 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.
- mistercow 14y ago>In this way it mimics the way we build sentences, that's smart. That's intuitive. That's Ruby. 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.
- goatslacker 14y agoThis explanation is an excellent way to teach and vs &&.
- tinco 14y agoI 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.
- pyre 14y ago| 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
- vq 14y agoI think Haskell wins out here since it has neither in the core language. Much easier to reason about. ;)