http://qs1969.pair.com?node_id=1161265

I've been a programming dabbler on an off for the past sixteen years or so (not counting the year I learned Apple Basic as a kid). I've recently gotten heavily back into programming for a couple of largish personal projects; most recently a event aggregator for the community where I live. For the last project, I decided to take a stab at doing OO Perl because too often I found that my procedural code for larger projects often degraded into spaghetti code as I dropped in more and more code to address all the edge cases that inevitably cropped up.

Fortunately, I had worked some with "old school" OO Perl in the past, just to get familiar with it. I had also played a little with other OO-oriented languages so was pretty familiar with most of the concepts. Still, I had to dig out my worn copy Damian Conway's "Object Oriented Perl" book written back in 2000 to refresh myself. But after writing a fairly modest program with old school OO Perl, it became apparent that it's probably not practical for a less experienced programmer like me to use old school OO Perl for bigger, more complex projects like the event aggregator I was trying to build. I had to waste too much effort worrying about whether I was using Perl properly to implement OO design and grok all kinds of advanced programming techniques to make it all work.

Then some Monks here recommended that I try Moose. I had never heard of Moose but, man, I am extremely glad I took their advice. Over the past month or so that I have been working with Moose, I found it to take a lot of the tedium out of programming and it has made it a much more joyful and less frustrating experience for me. When I see my code taking on the form of stringified pasta, I can easily break the code down into discrete chunks that makes it much easier for me to focus on the big picture of the program's structure and less on the detailed ins and outs of what the code is doing. I have a lot left to learn with Moose but there seems to be little question at this point in time that Moose will make me a better, more productive programmer and will help me create much more maintainable code. I can't see myself using anything but Moose for all but the simplest of scripts.

I'm wondering if other Monks who have tried Moose have similar feelings as me. Maybe I was just horrible procedural programmer. Have you tried Moose and then abandoned it? Right now I don't see any downsides to using it (my scripts don't have to run fast), but I'd be interested to know if you have a different take on Moose. Are there any limitations inherent to Moose that I should be aware of?

$PM = "Perl Monk's";
$MCF = "Most Clueless Friar Abbot Bishop Pontiff Deacon Curate";
$nysus = $PM . ' ' . $MCF;
Click here if you love Perl Monks

Replies are listed 'Best First'.
Re: Bullish on Moose, how about you?
by Your Mother (Archbishop) on Apr 22, 2016 at 23:13 UTC

    Opinions here vary somewhat widely—you can find love letters and haters comingled— but Moose is largely appreciated. I prefer Moo because I like its syntax a little better, it's quite a bit faster (for command line especially), and I have, rarely, maybe never, needed the intense levels of class control, generation, introspection and such that set Moose apart.

    I encourage you to explore some side-cars like Type::Tiny.

      I'm hoping Monks will post some tiny snips of code that shows *how* these modules save time and effort. It's one thing to go read the documentation, but another if code-compare examples are presented.

      I like the sound of things like Type::Tiny

        The main reasons I like/use Moo, etc, are to share behavior in a larger application (like a Catalyst application where the model is needed by the controllers, the tests, and the command line) and to wrap up, normalize, and auto-document, complex behaviors of conjoined simple parts that would otherwise quickly become spaghetti; make things like push and @{$object->{bunch_of_data}} semantic, less dense. This web spider stub is off the top of my head so take it as a terse draft but it shows the kinds of things I like to do–

        package MooSpider; use Moo; use MooX::HandlesVia; use Carp; our $VERSION = "42"; has "_pages" => is => "ro", handles_via => "Array", default => sub { [] }, handles => { pages => "elements", queue_page => "push", next_page => "shift", }; has "agent" => is => "lazy", isa => sub { confess "Need a flavor of WWW::Mechanize" unless eval { $_[0]->isa("WWW::Mechanize") } }, handles => [qw/ get post request links uri success response /]; sub _build_agent { require WWW::Mechanize; WWW::Mechanize->new( autocheck => 0, agent => join("/", __PACKAGE__, $VERSION) ); } sub crawl { my $self = shift; return unless my $uri = shift || $self->next_page; if ( $self->get($uri) and $self->success ) { $self->queue_page($_->url_abs) for $self->links; } else { carp "Problem fetching ", $self->uri, $/, "Moving on to next link"; $self->crawl; } $self->response; } 1; my $spider = MooSpider->new; $spider->crawl("http://example.org"); print join($/, $spider->pages), $/; $spider->crawl; print join($/, $spider->pages), $/;

      Why use Type::Tiny? Because it works with other OO frameworks?

      $PM = "Perl Monk's";
      $MCF = "Most Clueless Friar Abbot Bishop Pontiff Deacon Curate";
      $nysus = $PM . ' ' . $MCF;
      Click here if you love Perl Monks

        Yes; one type library for your app/company or whatever can be used anywhere including standalone/tests and the like. And because it's just really well designed software. Teh Inkster's stüfs are worth investigating in general.

Re: Bullish on Moose, how about you?
by Corion (Patriarch) on Apr 22, 2016 at 21:11 UTC

    There have been many discussions of Moo-style object helpers. tye made some comments in earlier discussions and I guess the complete threads there are worth a read too.

Re: Bullish on Moose, how about you?
by dsheroh (Monsignor) on Apr 23, 2016 at 08:42 UTC
    Yes, I've tried Moose and abandoned it. While I understand that its declarative syntax is quite popular, I don't feel that it really adds anything beyond overhead and absurdly long stack traces. I like traditional Perl OO, warts and all, but I'm also aware that I seem to be in a distinct minority. Like you, most people talking about their discovery of Moose absolutely love it, so you're definitely in good company, but there are a few of us heretics around, too.
Re: Bullish on Moose, how about you?
by Discipulus (Canon) on Apr 23, 2016 at 16:44 UTC
Re: Bullish on Moose, how about you?
by stevieb (Canon) on Apr 22, 2016 at 23:02 UTC

    I've written a couple of decent sized distributions in which I do use OO, but I've never taken the time to use, or even really try Moose. It's all old-school my $self = shift; stuff, with manual getter/setter writing.

    Hearing your brief on the subject makes me think I should have a peek... that said, I think I'll check out what Corion posted above in Re: Bullish on Moose, how about you?, and wait for other Monks to post. I knew that modules could help automate OO code, but I'm still not sure in p5 whether the dependency chains are worth it.

Re: Bullish on Moose, how about you?
by ctilmes (Vicar) on Apr 23, 2016 at 18:25 UTC

    I like Moose, but it is a rather heavy approach.

    Of late, I've grown fond of the Mojolicious approach with Mojo::Base.

    It has been broken out into Object::Simple, which is marvelously easy to use and very expressive for simple things.

    If you need the very complicated features of Moose, Moose does a great job at what it is.

Re: Bullish on Moose, how about you?
by Arunbear (Prior) on Apr 26, 2016 at 10:55 UTC
    Are there any limitations inherent to Moose that I should be aware of?
    • It's a juggernaut both in terms of installation and the start up cost it imposes on your scripts
    • It encourages Tight coupling and therefore discourages Modulariszation. Giving up Modulariszation negates most of the benefits of OOP
    If you're up for a challenge that shows the limitations of Moose, try implementing in Moose a queue which never has more than N items in it and maintains that size by evicting the oldest items (N would be specified when creating the queue).
      If you're up for a challenge that shows the limitations of Moose, try implementing in Moose a queue which never has more than N items in it and maintains that size by evicting the oldest items (N would be specified when creating the queue).

      A pointer to previous art might be useful here.


      With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority". I knew I was on the right track :)
      In the absence of evidence, opinion is indistinguishable from prejudice.