in reply to Re^3: Perl Vs Ruby
in thread Perl Vs Ruby

Actually I don't trust benchmarks I haven't manipulated by myself! 8 )
... but I'm a little disappointed you can't point me to a good argument to use ruby.

You think that factor 3 doesn't count, but a webadmin might reject to realise his template engine in C.

Cheers Rolf

Replies are listed 'Best First'.
Re^5: Perl Vs Ruby
by Joost (Canon) on Nov 26, 2008 at 20:26 UTC
      Speed is not everything, but with a factor 3 tolerance, one might realize plenty of syntactic sugar and OOP in perl! Things the community normally rejects because of "slowness".

      e.g. using lvalues and ties for attributes -> A tale about accessors, lvalues and ties

      Cheers Rolf

      UPDATE: IMHO, with factor 3 you can completely emulate Ruby within Perl, e.g. with autobox

        AFIACT, most of the slowness in Ruby is down to the implementation of the interpreter, not particularly due to its OO interface (and syntactic sugar is just a one-time compile hit, and the compiler/parser is plenty fast in both perl & ruby).

        But yeah, you could implement something similar to ruby on top of perl if you're willing to sacrifice some speed. The problem with doing that, is that you'll end up with a fancy OO framework that isn't used by 90% of the code out there, which means you won't be able to use much of it when you're interfacing with most CPAN modules.

        See Moose - which looks pretty nice but isn't even trying to offer much above some OO syntactic sugar (nothing like a standardized collection / iterator interface, for example) on top of Class::MOP. If Moose and Class::MOP would have been in the core since perl 5.0, much of the collection constructs would probably have been built on top of them, and been much cleaner and extensible/swappable with user types because of it (and tie is an annoying hack). That's one of the most important things that Ruby offers over perl.

        In languages like ruby & perl, OO is such a common need that the basic interface and conventions just HAVE to be worked out by the standard library, or you'll end up with a mess of third-party extensions all using more or less similar, but in practice non-interchangeable, interfaces - and being able to swap implementations around without changing the code that uses them is one of the most important uses of OO.