Is Moose the best for Perl object-oriented programming?

T

Tim McDaniel

I foolishly agreed to give a talk at the Austin Perl user's group on
object-oriented programming in Perl. Originally, I was supposed to
talk about inside-out classes, but I decided to look at what
object-oriented modules are available, in case there was something
great and new, or in case Perl 5.10 had something spiffy.

When I started Googling, I hit Web pages that stated that Moose is the
best thing since sliced beer. The examples that I've seen did look
spiffy, making it look as easy as R?by.

In case other people have already researched this, I'd like to put out
a request for reviews: is Moose the greatest object-oriented
programming module for Perl, or at least equivalent to the greatest
out there?
 
T

Ted Zlatanov

On Fri, 2 Jan 2009 18:16:20 +0000 (UTC) (e-mail address removed) (Tim McDaniel) wrote:

TM> When I started Googling, I hit Web pages that stated that Moose is the
TM> best thing since sliced beer. The examples that I've seen did look
TM> spiffy, making it look as easy as R?by.

TM> In case other people have already researched this, I'd like to put out
TM> a request for reviews: is Moose the greatest object-oriented
TM> programming module for Perl, or at least equivalent to the greatest
TM> out there?

You should look at performance numbers. For me, Moose took between 20%
and 50% more time than regular Perl OO to do the same work. This is
fine in some situations and terrible in others.

I'm not making a feature comparison, just timing simple get/put field
accessors. I understand all the ways in which Moose is wonderful but
they may not be relevant if you need speed.

Ted
 
T

Tim McDaniel

You should look at performance numbers. For me, Moose took between 20%
and 50% more time than regular Perl OO to do the same work. This is
fine in some situations and terrible in others.

I'm not making a feature comparison, just timing simple get/put field
accessors. I understand all the ways in which Moose is wonderful but
they may not be relevant if you need speed.

Thank you for the comments.

To expand on "fine in some situations": one has to be careful to test
in the context of the intended application. One major Perl ap I wrote
takes only several minutes to run and is run once per month. Another
runs 90 minutes, but that's dominated by calls to MySQL and Perforce.

In general, I've generally found it useful to worry first and most
about correctness, and only then consider performance: tweak or
restructure only to the extent that performance is bad.
"Micro-optimization gets micro-results", and
"if it ain't broke, don't fix it", and all that.
 
U

Uri Guttman

TZ> On Fri, 2 Jan 2009 18:16:20 +0000 (UTC) (e-mail address removed) (Tim McDaniel) wrote:
TM> When I started Googling, I hit Web pages that stated that Moose is the
TM> best thing since sliced beer. The examples that I've seen did look
TM> spiffy, making it look as easy as R?by.

TM> In case other people have already researched this, I'd like to put out
TM> a request for reviews: is Moose the greatest object-oriented
TM> programming module for Perl, or at least equivalent to the greatest
TM> out there?

TZ> You should look at performance numbers. For me, Moose took between 20%
TZ> and 50% more time than regular Perl OO to do the same work. This is
TZ> fine in some situations and terrible in others.

also note the compile time. i recently compared (on a very slow box)
template::teeny which uses and loads moose vs template::simple which
loads very little. the times for just one run were extremely slow (2-3
seconds) with teeny and a fraction of a second with
template::simple. this won't matter on long running servers but for
one run programs it may make a difference. moose is a large system and
not something you want to always load into small programs.

i am not against moose in general (i even helped optimize it during a
hackathon a couple of years ago at chicago::yapc) but i feel it is
overkill in some situations. i don't like seeing half of cpan installed
when i install a new (and seemingly small) module. dependency on large
amounts of cpan is a set of bugs waiting to happen (and it will!).

uri
 
T

Ted Zlatanov

On Fri, 2 Jan 2009 20:40:04 +0000 (UTC) (e-mail address removed) (Tim McDaniel) wrote:

TM> In general, I've generally found it useful to worry first and most
TM> about correctness, and only then consider performance: tweak or
TM> restructure only to the extent that performance is bad.
TM> "Micro-optimization gets micro-results", and
TM> "if it ain't broke, don't fix it", and all that.

The problem with Moose is that if you rely on its features, it may be
very painful to worry about performance later. It's an OO framework,
not an algorithm with clear API entry points. In particular, method
attributes (including data type hints) can be hard to replicate if your
code relies on them to enforce data integrity.

Ted
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top