in reply to Ruby Before Perl? Nah.

As to the lack of sigils and arrays and hashes both being indexed with square brackets, that gets more into the Ruby tendency to favour interface polymorphism (or as it's often referred to, "duck typing"). So long as what you're calling the [] method on responds to that method, everything is hunky-dory and it allows for some nice flexibility. I think the example given in one of the books was code which was using a string IO instance with << to build up something for output and the temporary objects were killing performance; they swapped to passing in an array which also groks << (and then called join afterwards once) and the app went from terrible multiuser performance back to acceptable (or something along those lines).

Not that this approach doesn't also have issues (e.g. you call method zorch expecting the object to do foo, but instead it does bar and wipes your hard drive . . .), but there is a rationale behind it.

And also there is a more traditional looking for loop, but it's really (mostly) syntactic sugar for calling each: 

for var in iteratable
  puts "Frobnicated: #{var.frobnicate}"
end

## is pretty much just the same as this . . .

iteratable.each { |var| puts "Frobnicated: #{var.frobnicate}" }

[download]

But really that's like persisting to use C-style loops in Perl . . . :)

The cake is a lie.
The cake is a lie.
The cake is a lie.

Replies are listed 'Best First'.
Re^2: Ruby Before Perl? Nah.
by Porculus (Hermit) on Jun 06, 2008 at 23:36 UTC
    Not that this approach doesn't also have issues (e.g. you call method zorch expecting the object to do foo, but instead it does bar and wipes your hard drive . . .), but there is a rationale behind it.

    I'm used to seeing posts like this explaining Ruby's object system when it's being contrasted to C++ or Java, but is this really noticably different from Perl's OO system? How does foo.zorch in Ruby differ from $foo->zorch in Perl? If it looks like duck typing and quacks like duck typing... ;)

    Indeed, I believe we could use Perl's OO support and operator overloading to do exactly the same things as Ruby does, right down to accessing arrays and hashes with the same kinds of bracket. The reason we don't is twofold:

    • Abstraction on the "everything is an object" scale is inefficient. Perl hackers prefer to save it for where it makes their code easier to read and write, instead of religiously abstracting everything just because we can.
    • Code is more maintainable when different things look different. Arrays and hashes have very different semantics.
[reply]
[d/l]
[select]

      Good points.

      The wikipedia article I referenced says "Perl's runtime method call mechanism naturally supports duck typing.". The thing is I think people writing Perl don't tend to think "the duck typing way" (if one might posit such a thing) to the extreme that Ruby encourages it. Not to mention that if you really want to in Ruby you can individually override / extend a single instance at runtime to implement an interface if need be (of course with Moose and friends you can do similar in Perl, so . . . ).

      And yes, there's overhead to the smalltalkesque everything's-an-object everything's-done-sending-messages model. Ruby's still got speed issues, but it's still got lots of elegant points. I'll often whip first passes of CSV munging together using Ruport because Ruport::Data::Table allows some really succinct code; if speed's an issue then it's time to drop back to Text::CSV_XS or Tie::Handle::CSV.

      The cake is a lie.
      The cake is a lie.
      The cake is a lie.

[reply]
        The thing is I think people writing Perl don't tend to think "the duck typing way" (if one might posit such a thing) to the extreme that Ruby encourages it.

        I find it more likely that the Perl community doesn't fall all over itself to drool all over itself and slap new silly names on decades-old techniques blatantly and obviously ripped from other languages as do some parts of the Ruby community.

[reply]

In Section Meditations