Slash Boxes
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

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
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.

    • 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:


      - 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:


        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 ;)


    • 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: []

    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