Live data from Hacker News

Ruby Demystified: and vs. &&

blog.tinfoilsecurity.com

71–74 of 74 posts

Re: Ruby Demystified: and vs. &&

#71
post #60

Not that I want Ruby to be anything like PHP and Perl, but this is the same thing that happens in those languages due to the difference in precedence of and, &&.

It's no accident. Ruby is heavily influenced by Perl.

Oh I know... someone said ruby is two parts Perl, one part Python, and one part Smalltalk. I like to think it's a bit less Perl than that, but my judgement is clouded - I'm a bit of a Perl hater.

Re: Ruby Demystified: and vs. &&

#72
post #60

Earlier quoted context omitted.

It's no accident. Ruby is heavily influenced by Perl.

Oh I know... someone said ruby is two parts Perl, one part Python, and one part Smalltalk. I like to think it's a bit less Perl than that, but my judgement is clouded - I'm a bit of a Perl hater.

I think it's a little less Perl than that, and a little more Lisp than that.

I don't have enough Perl experience to have a strong opinion on it, but I know that Matz says he created Ruby because he wanted a language that was more powerful than Perl and more object-oriented than Python.

Ruby is a little bipolar in that sense. It's both highly functional and highly object-oriented, for an imperative language. Even more of a "Swiss-army chainsaw" than Perl.

Re: Ruby Demystified: and vs. &&

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

Nothing is wrong with that. However the actual Perl open() would be like this...

  open my $fh, '
Above two lines are equivalent.

Re: Ruby Demystified: and vs. &&

#74
post #14
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`…

I think Haskell wins out here since it has neither in the core language. Much easier to reason about. ;)
Post reply on HN