Re^7: Perl Vs Ruby

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.

"What should it profit a man, if he should win a flame war, yet lose his cool?"

Comment on Re^7: Perl Vs Ruby Download Code

Replies are listed 'Best First'.
Re^8: Perl Vs Ruby by stvn (Monsignor) on Nov 26, 2008 at 22:23 UTC
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 This is because Moose is not trying to implement a standard library or collections framework, it is only trying to make OO nicer. And while I agree that a standard library is a good thing in theory, practice has shown that one size does not always fit all (see also - Ocaml's standard library, all the Java frameworks that have gotten traction in recent years, etc). Perl is a community (for better or worse) of strongly opinionated people, getting people to agree on some "standard" would take forever (see also - Perl 6 RPC process). 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. FWIW, Moose is built specifically to play nice with non-Moose CPAN modules and legacy non-Moose code (I have several partially Moosified apps in production). Moose would be absolutely useless IMO if it forced you to re-write everything in Moose and that was one of it's key design goals (otherwise $work would have probably just switched to Ruby or Python). 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, I disagree with you here in regards to Perl. In Ruby they had to create a "standard library" of classes (Array, etc) because "Everything is an Object", whereas in Perl you could consider the standard library to be built-in (non-OO) arrays, hashes, scalars and the functions that operate on them. -stvn	[reply]
Re^9: Perl Vs Ruby by Joost (Canon) on Nov 26, 2008 at 23:18 UTC
I'll take your word for the compatibility features of Moose. I haven't seriously used it (yet). I disagree with you here in regards to Perl. In Ruby they had to create a "standard library" of classes (Array, etc) because "Everything is an Object", whereas in Perl you could consider the standard library to be built-in (non-OO) arrays, hashes, scalars and the functions that operate on them. The problem is, perl's standard containers are conceptually objects just like custom-made perl objects, except the interface to them is completely different. So different in fact, that you can't use the standard iteration constructs (like foreach and while each), or calling/accessing ops (like (), [] and {}) on anything that implements a "normal" OO interface. And THAT means you can't use the familiar iteration constructs on any user-defined object, unless it sacrifices easy access to other potentially useful methods. In other words: the problem isn't that arrays and hashes aren't objects, the problem is that the perl programmer cannot reasonably define his own datastructures that can be accessed using the same interface the build-in types use. It's a problem of (access to/lack of) well-defined interfaces. And I stand by my assessment that tie() is an ugly hack that only half-way overcomes this issue. "What should it profit a man, if he should win a flame war, yet lose his cool?"	[reply]
Re^10: Perl Vs Ruby by stvn (Monsignor) on Nov 27, 2008 at 17:54 UTC
In other words: the problem isn't that arrays and hashes aren't objects, the problem is that the perl programmer cannot reasonably define his own datastructures that can be accessed using the same interface the build-in types use. It's a problem of (access to/lack of) well-defined interfaces. And I stand by my assessment that tie() is an ugly hack that only half-way overcomes this issue. That I will completely agree with, tie() is horrid and it would be nice to be able to define something that is compatible with standard @ and % without having to use tie() to get there. The inverse is possible now though via autobox and we have tried to make a semi-standard API (based heavily on the Perl 6 stuff) with Moose::Autobox. -stvn	[reply]
Re^11: Perl Vs Ruby by Joost (Canon) on Nov 27, 2008 at 20:37 UTC
Re^8: Perl Vs Ruby by LanX (Saint) on Nov 26, 2008 at 22:25 UTC
> (and tie is an annoying hack) Isn't it ironic that your so in favour of OOP and in the same time reject tie, which is essentially nothing more than a pimped up bless? It's reliable, you can hide it behind syntactic sugar, BUT it's as slow as the rest of Perl OO. But hey, wait! Didn't you just explain that slowness doesn't matter ...??? ; ) Cheers Rolf PS: Thx for the insights in Ruby, I agree about some syntactic annoyances in Perl 5, and I'd really love to have Perl 6 syntax right now mapped on Perl 5 semantics and interpreter... sigh! : (	[reply]
Re^9: Perl Vs Ruby by Joost (Canon) on Nov 26, 2008 at 23:22 UTC
The slowness isn't an issue, the fact that it doesn't integrate AT ALL with the "normal" OO interfaces really is. See also Re^9: Perl Vs Ruby "What should it profit a man, if he should win a flame war, yet lose his cool?"	[reply]