From: Robert Klemme <shortcutter@...>
Date: 2009-02-10T05:49:58+09:00
Subject: Re: Ruby vs Perl performance

On 09.02.2009 19:15, David Masover wrote:
> Robert Klemme wrote:
>> Yes, you can program OO style in Perl and there is /some/ support for
>> this - but it does not really give you much advantage over doing OO in
>> C (yes, you can do that: even std libraries do it, see open and fopen
>> et al).
> 
> I haven't done enough C to say for sure, but I loved Perl's OO. There 
> definitely seems to be more there -- inheritance via @ISA, constructors 
> via bless -- and while some find it ugly to expose all the 
> underpinnings, that is one thing I love about Perl.

It's not that I find it "ugly".  It's more that I find it hard to read 
and remember whichever you have to do to get a class, inheritance, 
methods, data members etc.  IMHO Perl makes OO unnecessary hard.  There 
is a paper written by Larry Wall about the flaws of Perl's OO which I 
cannot seem to find right now.

> It's also one of the same reasons I love Ruby -- I don't have to get my 
> hands dirty.

"Same reason"?  That sounds strange to me.

> Take the simplest example, a method. In Ruby, it'd be:
> 
> class  Foo
>   def bar(arg)
>     ...
>   end
> end
> 
> In Perl (and forgive my syntax, it's rusty), it'd be something like:
> 
> package Foo;
> sub bar {
>   my ($self, $arg) = @_;
>   ...
> }
> 
> Now, the Ruby version is much more readable to me, and much easier to 
> work with.

Exactly!

> But there is something magical about the way the Perl version 
> starts from even more basic primitives.

Frankly, I don't like magic in programming - at least not the kind of 
magic that makes it hard to follow a program when reading it.  I have 
had to maintain too much cryptic code to not highly appreciate readability.

> Arguments are simply passed in 
> as an array, which you can either unpack or not, as you like.

You can do that in Ruby as well.  Just do

def initialize(*a)
   what, ever, you_like = a
end

> The 
> current object is passed in as an argument, meaning this is just another 
> subroutine -- it lets you do tricks like this:
> 
> my $foo_like_thing = Bar::new();
> Foo::bar($foo_like_thing, $some_other_arg);

What does this?  Does it create a Bar and then initializes it as Foo? 
What do we gain from that?  Where is the advantage over declaring 
classes Foo and Bar and making Bar a subclass of Foo if they are so 
closely related?  (Or use a module for that matter)

> Kind of like Javascript's call() and apply() -- and I'm not even sure 
> this can be done in Ruby. For all the duck typing goodness, I can't seem 
> to figure out how you'd unbind a method and rebind it to something of an 
> unrelated class, unless there's an explicit tree of inheritance.

Why would you want to do that?  There's a reason why both classes are 
unlrelated, i.e. chances are that the method would not work in the other 
class / object.  If you want to simply share code then you can use 
modules which is a much cleaner and safer way to do it.

> Not that this is something I've often (ever?) felt the need to do in 
> Ruby. I'm just using it to illustrate what I like about Perl -- that 
> it's so completely relaxed about this kind of thing. It gives you the 
> bare bones of what's necessary for an object system, and you build 
> whatever you want on top of it -- even with the guts exposed all over 
> the place.

The problem with this is: you _have_ to build it yourself.  If I only 
get the basic building blocks and have to reapply them over and over 
again to get the same result (a bunch of classes with methods and state) 
then I am wasting time.  A genuine object oriented language is much 
superior.

Kind regards

	robert