From: David Masover <ninja@...>
Date: 2009-02-12T09:09:48+09:00
Subject: Re: Ruby vs Perl performance

Robert Klemme wrote:
> On 10.02.2009 19:42, David Masover wrote:
>> Robert Klemme wrote:
>>>> That's arguably better, but a bit more work at the beginning. 
>>>> Still, it's
>>>> worth comparing to the Perl solution:
>>>>
>>>> sub init {
>>>>  my($class, $self) = @_;
>>>>  bless $self => $class;
>>>> }
>>>>     
>>> But this does not set properties, does it?
>>
>> It does, actually, assuming you called it with a hash of options. 
>> Perl objects are most commonly a blessed hash.
>
> That's the first flaw of Perl's OO: you have the free choice to use 
> hashes or arrays (or even scalars?) as objects.

Why is this a flaw? In Ruby, everything's an object. On closer 
examination, we use instance variables in objects more or less the same 
way a Perl object would use hash members.

>>
>> thus creating a spontaneous new child of both Foo and Bar. Keep in 
>> mind that both Foo and Bar are classes, each of which may have 
>> methods of their own -- in this case, Bar's methods (or properties) 
>> override Foo's.
>
> Really?  I'd say they are overridden by Foo's because this comes 
> later.  But I'm not a JavaScript expert.

Since Foo is a user-definable function, it's actually entirely up to the 
author of said function. I believe the sample I gave was using the 
argument to override defaults in Foo.

>> To get something even close in Ruby, I'd have to do this:
>>
>> f = OpenStruct.new
>> class << f
>>   def c
>>     #some method
>>   end
>> end
>
> No.  This is a one off shot.

You're right. I was simplifying.

> To get the equivalent of the JavaScript version (if my JS does not 
> fail me), you need to define a method which does the initialization, e.g.
>
> def Foo(o = Object.new)
>   class <<o
>     attr_accessor :bar, :baz
>
>     def c
>       printf "bar=%4d, baz=%4d\n", bar, baz
>     end
>   end
>
>   o.bar = 123
>   o.baz = 890
>
>   o
> end

I suppose that is roughly equivalent. I would have chosen something 
else, like:

module Foo
  def a
    ...
  end
  ...
end

def foo(o = Object.new)
  o.send :include, Foo
end

So, you can get close with something like:

foo(
  OpenStruct.new(
    :a => 'some_string',
    :b => 12345
  ).extend(Module.new {
    def c
      # some method
    end
  })
)

I don't know about you, but that reads a lot less naturally to me. 
Fortunately, Ruby is flexible enough that if I really wanted it, I could 
probably define some DSL that does the right thing -- something like:

foo(MyStruct.new {
  a 'some_string'
  b 12345
  c do
    # some method
  end
})

> The details really do not matter.  My point is simply this: I prefer 
> to use Ruby over Perl because of the clean syntax as well as the 
> profound OO.  And I still have all (or at least most of) the options I 
> have in Perl's bare metal world.  I find the balance in Ruby highly 
> superior.

I agree. Or rather, not so much because the OO is profound, but because 
it is much cleaner to access, for most things.

>>> Because in Ruby hackery (or call it "metaprogramming") is an add on,
>>> i.e. you can use it in special situations, while in Perl you need to
>>> do it to get basic things (OO) to work.
>>
>> There are, however, libraries to make the OO less painful in Perl.
>
> Which still makes them non core artifacts and leave the option for 
> multiple OO models in the same program.

I don't see that being more of a problem than duck typing vs other 
models in Ruby.

If you want to be consistent within a program, write up a coding style 
for that program. If you want your language to enforce a coding style, 
Java and Python will each do that for you, in their own ways.

>> Now, not doing that often is probably a good idea -- not using 
>> Kernel#eval often might also be a good idea. But I don't like it when 
>> a tool tells me what I may or may not do, simply because it's not a 
>> good idea.
>
> Maybe you haven't come to appreciate the power gained from 
> restriction.  Often more creativity and productivity is unleashed in 
> more restricted environments.

Like Picasso's Blue Period, I get it. And it can certainly be useful for 
learning.

I still don't see why it's good for the _environment_ to do that 
restriction, rather than making it self-imposed. Certainly, I almost 
never allow myself to use eval, and my code is better for it -- but note 
that key word. _Almost_ never.

>> I'm not trying to sell Perl's OO as the best thing, or even "better". 
>> But I'm defending it as inherently less useful than Ruby's.
>
> Is this really what you intended to say?

Probably not. Probably "defending it as _not_ inherently less useful..."

>> Someone might as easily say that Ruby's OO is inherently less useful 
>> than Java's, because Java does stricter (static) type-checking.
>
> As always it depends on the point of view - or the criteria you apply. 
> I do mostly OO programming - even in scripts - and for that I 
> appreciate the way OO is done much more than Perl's way.

I do mostly OO programming, and I prefer Ruby -- but as a matter of 
taste. I've just had enough experience with Perl to respect it, too, 
even its object system.

I've also had enough experience with PHP to lose all respect for it... 
The problem with PHP is they have absolutely no taste. (Apologies to 
Steve Jobs.)