Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

scrottie (4167)

scrottie
  scott@slowass.net
http://slowass.net/

My email address is scott@slowass.net. Spam me harder! *moan*

Journal of scrottie (4167)

Wednesday January 14, 2009
04:27 PM

Why not Moose

[ #38289 ]

Ooops, I chose my words poorly and created rather more contraversy than I meant to. Please read this instead: http://use.perl.org/comments.pl?sid=42086&cid=66942. This is here for historic whatever.

-----------------

Moved this over from the Squatting mailing list so as not to spam it.

I feel about Moose about the same way people used to feel about Damian Conway's old Switch.pm module, except that Moose is also bloatware.... that is, it's a great prototype for how syntax could or should look and how things could or should work, and it's okay to use it internally for projects, but it's very bad form to release code to the outside world that depends on it. Source filters cause a lot of problems... so does Moose and all of its deps. Like previous, recent posts here, stack traces turn into nightmarish explosions a hundred lines long. It's a leaky abstraction (see Joel on Software's essay on leaky abstractions) where if you don't know how it works under the hood, you'll get bit in the ass, or at least have to cargo cult code, only using it ways and doing things with it that you've seen other people do and get away with. Like Switch.pm, it just boils down to the abstraction being too leaky. And that's why it shouldn't be inflicted on strangers as a dep, why it shouldn't be standard fare for code, and why it should be considered a prototype for ideas to later be possibily implemented in core.

The power of Perl is gluing things together. A lot of fun comes from picking two modules and just using them together. But Moose, like POE, has created a "shadow CPAN", of modules that require it and only work with it. Besides demonstrating how leaky the abstraction is, this segments camps that should be unified. It also generates spam and busy work, keeping busy rewriting modules like BoneEasy to be Moose plugins.

I'm all for syntax sugar, but if it takes 20,000 lines of code to get your fix, you've got a problem. Your code is the equivalent of the lady in the electric scooter desperately trying to reach the pound cake at standing chest level.

-scott

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • I get the sense that many people have given up on the core being useful beyond small projects. Certainly Perl 5 hasn't found the optimal solution to code reuse.

    • Re: core, this is the same-old same-old.

      There's talk of adding a method keyword and parameters. That's good.

      But what seems to be happening, and what always seems to happen in Perl land, is that it happens in a module, it percolates a long time, then just enough is added to core that the module can function well. Whether something like Moose winds up in core doesn't matter as long as perl itself can reasonably accommodate it.

      This is good laziness -- how little do the perl 5 porters have to do and risk brea

  • You are certainly entitled to your opinion and I wont try to convince you to use Moose as I am sure your opinion is not knee-jerk, however I would like to just address a few points.

    To start with, Moose is still a work in progress and is in no way up to the level of sophistication as say a full blown language, so there will be some dark and ugly corners sometimes. Some of the things we are currently working on are both startup speed (we can't reduce the "bloat", but we can at least make it less noticable)

    • Why isn't something like Moose::Error::Croak the default behaviour?

      Sure, it's convenient for Moose developers to see the stack trace. But it's very inconvenient for application programmers using Moose to be exposed to internal details, useless for debugging the mistake they just made.

      The most interesting difference between these two groups of people is that the Moose developers already know more about Moose, and how to turn the stack trace on. Moose users don't, so a sensible default would be to cater to th

      • Why isn't something like Moose::Error::Croak the default behaviour?

        Well, *I* like stack traces, both when I am developing Moose and developing with Moose. In fact, before I even wrote Moose I wrote Class::Throwable which not only gives stack traces, but allows nested exception re-throwing so you can have multiple levels of stack traces (yes, that means a stack trace showing from where you re-threw the exception in addition to the stack trace of the original exception). Since until about 6 months ago I

        • "I will agree that the stack traces sometimes expose too much of the Moose internals"

          That was actually what I meant, I'm not averse to stack traces in general.

          But the few times I've seen them, I found that the internals part of the trace tended to drown out the information useful to find out why my "has" declaration was wrong.

          • I am hoping that careful usage of Carp::Clan will help this, the real issue is striking that balance between not enough information and too much information. It has been on my TODO list for a long time now, but as i said it is all about the tuits right now.

            - Stevan

    • Hi Steven,

      Thanks for taking time to read and comment on this. I'm often the voice of dissent (I hate POE, the various ORMs, Parrot, and lots of other stuff, too). So I'm always a bit surprised when I'm not dismissed as a crank =)

      Switch might be a source filter, but it's small and has no deps. As to whether Moose is as fragile as it, I can't honestly say. That was a bit knee jerk of me to say that. But to the extent that the analogy does hold (which might not be far), I'd like people to consider not rel

      • Again, most modules aren't used because they're the coolest thing ever, but instead because they're a dep of something else.

        When you write insightful things like this, I can never take you as a crank. Like you say, only when abstractions leak is this a problem.

  • Moose has it's issues... certainly the big memory overhead and the slow startup are issues.

    (Yes, I know they are working on it, and it's gradually getting better...)

    But even though it's heavy, source filters are up there in a whole different (worse) class of crazy, as it the original bad implementations of Inside Out objects.

    But you have to remember that this weight is there for a reason, and that's to allow not-brilliant programmers to do useful work without hurting themselves as seriously.

    • Switch.pm has no dependencies. It's short. Moose has many deps and lots of code. Certainly source filters carry a lot of bad juju. Moose is huge and complex. I can't honestly say that that makes it "as bad" as Switch, but I think the analogy is fair. Or, as I said in another comment, comparing it to Inline::C vs XS might have been more fair. When distributing modules on CPAN, it's much better to use XS. Using Inline::C, which though it's awesome and generally works well, you're piling magic on top o

  • One of the reasons I'd promote Moose for things you want on CPAN is that along with Moose will come a whole boatload of capabilities that will have a much easier time jumping into your project and usefully contributing. That way people spend less time trying to figure out your personal way of working around all the stuff Perl doesn't do for you out of the box and more time adding features and solving problems. Moose has a strong and growing ecosystem of best practices and shared knowledge that's a major a
    --
    Waiting on the Road to Eventually, I lost my Place On Line
    • Exactly!

      I think that the new Moose motto should be:

      TIMTOWTDBSCINABTE (*)

      - Stevan

      (*) There Is More Than One Way To Do It, But Sometimes Consistency I Not A Bad Thing Either

      • Whoops, actually messed that up some, that will teach me to respond to use.perl while on conference calls.

        So after some discussion on #moose, the new Moose motto is now:

        TIMTOWTDIBSCINABTE

        It is pronounced - "Tim Toady Bicarbonate", and stands for "There Is More Than One Way To Do It, But Sometimes Consistency Is Not A Bad Thing Either".

        - Stevan

      • Wait, this dingus's argument for using Moose is that "it comes with a bunch of features". If I'm install some module from CPAN not because I want it, but because I have to have it because someone else depends on it, I don't give a flying rat's ass if that module is imbued with the power of Moose.

        And also, as I said in another comment, it strikes me as odd that while the rest of the world is losing interest in Java and moving towards things like Ruby and obsessing over things like Smalltalk and Self, Perl i

    • Agree. I especially like what attributes with lazy defaults do to the code structure.

  • I wrote Class::Accessor::Classy because I was sick of the Class::Accessor approach of "you must inherit the meta class." This was when Moose was still very young, but I still don't see the speed in Moose. C::A::Classy certainly lacks a lot of the features of Moose, but it is fast and light enough to be a foundation for serious work without getting in the way.

    I do occasionally want something which Moose would provide beautifully, but paying speed/size for the whole thing while only using 2% of the features

    • Try "Badger" from Andy Wardley.

    • If you have commandline applications or CGI applications that are extremely response-time sensitive You should really see if Mouse can work for you. It's got more update and active development than any of the other OO frameworks from what I can tell, with speed as it's reason for being. That being said, I write commandline apps with Moose and find it more than responsive enough. Your sensitivity my be different than mine though.
      --
      Waiting on the Road to Eventually, I lost my Place On Line
      • Yup, I'm aware of Mouse. And I'd encourage people writing modules that have deps (which is what triggered the original post) to use it instead. I might even use it, but I enjoy doing other things too much >=)

        Speed is only one way in which the abstractions created by Moose leaks. I was just asking that people who write modules consider the law of leaky abstractions in general before using Moose in modules not related to Moose. And then doing some off topic bitching ;)

        Cheers,
        -scott

    • If I were writing an enterprise app, I'd seriously consider Moose, but what has me scratching my head is 30 line "helper" modules pulling it in. It reminds me of the Simpsons episode where the IRS took over Krusty Burger and Homer has to fill out a bunch of paperwork to get a burger. It's just comically top-heavy. Sure, the module helps, but at what cost?

      I wouldn't feel too bad if every program that used a module wound up with Mouse loaded, but if it happens that you can't use anything without Moose gett

  • The attitude where you "have to know how it works under the hood" or else you don't use it, is dumb, and leads to moronic efforts to reinvent wheels.

    Joel's buddy Jeff demonstrated this well when he decided to write his own HTML Sanitizer: http://www.codinghorror.com/blog/archives/001167.html [codinghorror.com]

    Engage cross-site scripting!

    And why are you whining about confess dumps? I presume because you are not used to seeing them, but the stacks are probably just as deep on most other modules you use, and you are oblivi

    • I hate repeating myself. It never accomplishes anything. But I'm a fool. So:

      I *said* that all abstractions leak. Whether or not you agree with that, I did introduce that as a premise in what I wrote, I also make it clear why I need to know what's going on under the hood -- not because I care, but because it *breaks*. Or leaks, to honor the analogy. But if you didn't catch that the first time, I doubt you will this time.

      I am perfectly used to seeing confess dumps. They're usually 20 or 30 lines long f

      • Nice retort; proper old school, especially the bit about your manhood :-)

        Thanks for clarifying your point of view - I'd have preferred you to say some of this in a rather longer (and less vague) original blog post, which might have saved me the time in the first place of wanting to jump on your head. Perhaps take that as a tip for any future Moose musings here.

        At the moment I'm toying with Moosifying one of my own modules. It would make the guts so much more sane and manageable, but offer no real benefi

  • This created a bit of a frenzy. I used some harsh words and wound up writing a lot more in replies than in the original comments.

    So, let me back up a bit here and qualify that. I know this doesn't undo the damage, but at least I can go on record.

    Moose has a cost. It might be low or high -- I'm not qualified to say and it's beside the point. If the value of your module is lower than this cost, please reconsider using Moose.

    Moose adds some startup time, which is of concern to CGI apps and command line app