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
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:On Core
scrottie on 2009-01-18T12:17:59
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 breaking, essentially.
So even though Moose is currently pissing me off and the garishness of it scares me, I think it's all part of this larger push in the right direction.
-scott
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) and error handling (if you don't like stack traces then you don't have to use them, see Moose::Error::Croak for details).
As for the leakiness of the abstractions, it is rare to find any abstraction that is 100% leak free. Stop and consider for a moment that Moose (and the underlying MOP) is an abstraction of a system for writing abstractions with, it would be really hard to keep it 100% leak free.
Lastly, I think your comparison to Switch.pm is way off. Switch.pm sucked because it was a source filter and therefore sensitive to the code used in and around it. Perl being the highly flexible language that it is, it was quite easy to write code within the switch blocks that did bad things when the macro was expanded. Moose is not and has never been a source filter, it does not have that issue. Sure it helps to sometimes know how things are working under the covers, but I must disagree with you that it is as fragile as Switch.pm is.
- Stevan
Re:
jplindstrom on 2009-01-15T14:42:44
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 their needs. Also, there are more of them.
Re:
Stevan on 2009-01-15T19:53:32
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 was pretty much the primary author of Moose, I did what I liked and what was good for me and my needs, which is stack traces. The whole reason Moose::Error::{Croak, Confess, Default} exist is because the other Moose contributors wanted a more pluggable system and so they wrote one, but the default remains confess because, well it's what I prefer (backwards compat and all that too).
Now, to say that stack traces are "very inconvenient for application programmers" is making a blanket statement about "application programmers" that is just flat out not true and is really just your (and scrotties) opinion (and surely a few others agree with you too, but certainly not *all* app programmers). I will agree that the stack traces sometimes expose too much of the Moose internals, and at some point I would like to add support for Carp::Clan or something so that we can filter that, but right now it is an issue of tuits (I don't have any and neither do the other core contributors, want a commit bit??)
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 their needs. Also, there are more of them.
Well there is one big flaw in that plan, which is that the more experienced Moose developers are also the ones with more code already out in production, which may or may not need to be changed because of this. These people have been loyal users and submitted bug reports, patches, etc. I wouldn't want to screw them over just to make it easier for a casual user to just "try Moose out".
- Stevan
Re:
jplindstrom on 2009-01-15T22:29:36
"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.
Re:
Stevan on 2009-01-16T00:37:25
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
Re:
scrottie on 2009-01-18T12:12:11
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 releasing modules that depend on Moose without a good reason. Using Inline::C vs XS probably would have been a better example. Even though Inline::C works pretty well, just out of respect for the time and energy of people using modules, it's better to use XS than Inline::C in CPAN modules. Again, most modules aren't used because they're the coolest thing ever, but instead because they're a dep of something else.
Anyway, I did write that Moose is good for prototyping these ideas, mechanism, and the syntax. I didn't mean to suggest that Moose shouldn't exist or is inherently bad. I'd just like to see people being realistic about it's cost -- like the old saying goes, Lisp programmers know the value of everything but the cost of nothing. Part of the cost is the little leaks that the abstraction does inevitably spring.
I am glad to see interest in fixing up OO in Perl -- capabilities, sugar, and everything.
Cheers,
-scottRe:
chromatic on 2009-01-18T17:58:42
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.
Re:Moose isn't as bad as Switch.pm
slanning on 2009-01-15T13:06:26
this weight is there for a reason, and that's to allow not-brilliant programmers to do useful work without hurting themselves as seriously.
You mean it's coded defensively, robustly? Well, I wish a few more "brilliant" programmers would try that. I thought it was because of all the metaclass/introspection stuff. (I'm recently liking Moose. Add a couple modules like MooseX::Params::Validate and MooseX::StrictConstructor, coercing parameters to types, before/after/around, ah it's not bad... Slower, maybe (compared to...?), but hey pass me that bong...)
Re:Moose isn't as bad as Switch.pm
scrottie on 2009-01-18T12:56:56
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 of magic, and it's a simple fact that the abstraction will leak. Memory and CPU is only one way the abstraction leaks. The stack trace thing is a (solvable, but real) example of another way it leaks. Failed dep installs are another.
I don't care if people use Moose in their own apps or in enterprise apps, but I'm seeing people write 30 line "helper" modules that use Moose and get sucked in as a dep five layers of deps down. That's just lame.
Ruby is getting a lot of attention for its OO, but it's also being praised for its minimal design aesthetic. An extremely feature rich OO thingie won't impress the Java people, and people don't even care about Java any more -- it's the Pythons and Rubys with simplicity and adaptability rather than some kind of "completeness" that impress people. It seems an awful lot to me like after lots of attempts at OO systems that clean up Perl's OO syntax and idiom, the mindset of the Perl community decided to concede that battle and start fighting a different one in stead, as a distraction -- and as it turns out, it's a lot easier to add a whole bunch of features to Perl's OO than it is to clean it up.
And I agree, the InsideOut object fad was lame and sucked. But will this one suck too, in retrospect? Remember, people were really into their inside-out objects for a while there.
-scott
Re:I feel very much the opposite
Stevan on 2009-01-15T19:57:19
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
Re:I feel very much the opposite
Stevan on 2009-01-15T20:03:33
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
Re:I feel very much the opposite
scrottie on 2009-01-18T12:43:25
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 is doing this. I know it's a bit out of reach of Perl at the moment, but a simple, general, adaptable, clean, minimal object system would beat a whole pile of features any day. One that you can build whatever abstraction you need with, rather than having those abstractions already built for you (which is of course an impossibility, as needs change with time and can't be predicted).
More features = better scares me. That's a Microsoft-esque mentality.
-scott
Re:I feel very much the opposite
jplindstrom on 2009-01-15T22:31:54
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 98% of the time simply doesn't work for me.
I wish Moose would run much faster and lighter, but it's difficult for me to see where investing my own effort (in both learning and contributing) would yield results with sufficient performance. Unfortunately, this was also true over a year ago. Until `perl -e 'require Moose'` clocks under 1/100th second, I'll simply have to keep working with something simpler.
I really do wish that I had nothing against Moose. That is, I wish there were "one really good way to do it" and that everyone did that. But, it has to perform or it doesn't fly.
Re:speed
sigzero on 2009-01-15T21:57:59
Try "Badger" from Andy Wardley.
Re:speed
jjn1056 on 2009-01-15T22:28:54
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.Re:speed
scrottie on 2009-01-18T12:30:45
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,
-scottRe:speed
scrottie on 2009-01-18T12:36:06
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 getting pulled in, I'm going to be annoyed.
But it's not just RAM and CPU... it's all the other ways in which abstractions can and do leak.
It's just too early for any one object system to win the object system war.
It also strikes me as odd that people are getting off on all of these features at a point when most of the programming community is tired of Java and interested in things like Smalltalk, Self, and so on.
But Method::Signatures++ =)
-scott
Re:speed
slanning on 2009-01-18T18:41:57
I just installed Method::Signatures. It required PPI, Devel::Declare::MethodInstaller::Simple (B::Hooks::OP::Check), Devel::BeginLift. Doesn't all this (presumed) perlguts manipulation seem....fragile?
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
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 oblivious.
Finally... surely the long dependency chain shows that the modules are used and maintained. A newcomer to CPAN has to base their choice from the multitude of Config modules (or whatever) on something, and the one the Moose/Catalyst/DBIC/POE folks use is probably a good bet.
Re:Why know how it works under the hood?
scrottie on 2009-01-18T12:28:18
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 for production code, not 100. But other people have pointed out modules that sanitize those. And I also thought (I don't remember) that I made it clear that the crash dump didn't confuse my simple brain but instead was a simple example of this leaky abstraction thing that I keep mentioning. By the way, if you reply to this, I'm not reading it, so now would be a good time to challenge my manhood and insult my mother.
No one is saying that code re-use is bad. But it's not black and white either. If code reuse is good, then why not suck in all of Bundle::CPAN? Code in modules is going to have less errors than re-invented wheels, but it's not error free either. Just like each line of code needs to move you a step closer to solving a problem, each module also needs to. I was trying to install HTTP::Proxy the other day and that got wedged with a dep five levels deep that was doing something completely unrelated to the original module's premise -- some helper programmer hanging off of an email module hanging off a MIME module had another little helper program that was barfing. Rather than being mindless about trying to re-use every bit of code out there, I'm calling for developers to be intelligent about it, even re-evaluating whether or not the modules they release use Moose.
Thank you for taking the time to comment in my blog even though you couldn't be bothered to actually read what I posted in it. Now go away and never post here again.
-scott
Re:Why know how it works under the hood?
oliver on 2009-01-18T13:38:37
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 benefit for the end user - and the deps chain might be a drawback as you say. But I will probably go ahead with Moose, because at the end of the day I develop this code on my own time, at my own cost, and this effort will reduce that cost (and probably mean more user feature requests get added, in the end).
Best of luck to you, and please, take a chill pill dude, my having opinions (even if strongly voiced) is no reason to get stroppy. Still, my thanks to you for taking the time to provide further details.
Re:Why know how it works under the hood?
rcaputo on 2009-01-20T02:31:31
A newcomer to CPAN has to base their choice from the multitude of Config modules (or whatever) on something, and the one the Moose/Catalyst/DBIC/POE folks use is probably a good bet.
To be fair, POE's requirements are quite lean. It only needs three nonstandard libraries as of Perl 5.8.9: File::Spec, Test::Harness and Test::More.
Re:Why know how it works under the hood?
doom on 2009-01-27T22:01:41
"The attitude where you 'have to know how it works under the hood' or else you don't use it, is dumb"When I hear about a perl module doing something whizzy, the first thing I want to know is if it's using a source filter. On top of all the other complaints you usually hear, source filters, even if they work correctly make it a pain to step through your code using the perl debugger.
And Scott's main point here is that excessive dependencies can be a pain -- if installing Moose bugs you, then yeah, you want to know if you're installing something that uses Moose. (I used to think that deps were a non-issue now because we're all using CPAN.pm or CPANPLUS.pm to handle them automatically... I've gotten enough complaints to conclude that many people are still doing it manually.)
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 apps. It does not however actually slow down running code, generally speaking. Accessors are highly optimized. When I talk about cost, I mean the whole complex set of bugs you might stumble over, the chance that it fails to install as a dep of something else, rough edges like Moose specific stuff in call stack traces, and whatever else. This is the "cost" I'm referring to. Everything has a cost.
If you're a Perl programmer you're a different creature from a CPAN module author (and the porters are different creatures yet). If you're a Perl programmer writing an app, use Moose! Unless of course you want to use something else instead. If you're a CPAN module author, then other factors come into play. Your module might be the dependency of another dependency and no one cares about your module at all other than they want it to install without problems, quickly, and without grief. In that case, whether I personally think you should use Moose or not is "it depends". An application developer doesn't have to worry about the cost. You do. Or at least I'd like you to, please =)
As far as Moose being "as bad as Switch", that was a bit harsh. I should have compared using Moose to Inline::C versus XS. I personally like to see modules that are light and themselves don't rely on a lot of magic, but I also realize there's an aesthetic going right now towards code re-use. There never was an aesthetic towards the use of source filters. Having deps is far more defensible than using a source filter. I'd rather any random module didn't import Moose but if you're writing a module and you actually benefit from using it, go for it. If it makes your code longer, I'm going to taunt you.
I'm back peddling here and I don't want to lose sight of that, but the lack of argument against something is not an argument for it. That's the fallacy vacuum cleaner salesmen use -- if you can't argue good reasons for not buying it, then of course, you have to buy it! Talking to people about Moose, I keep hearing things along the lines of "people should use it, because it only has problems in scenario X and Y, and that doesn't apply to them!". Again, that's not an argument for Moose, just one argument not against it.
It would be more respectful to people to hear pros and cons. It has pros. It's prototyping a lot of ideas coming up in Perl 6 and giving you access to them now. It gives you access to an ecology of OO helper thingies. Etc, etc.
I know the developers have heard over and over again about the startup time and size of the beast (in terms of code and modules used). This has probably overly polarized the matter. Just because this is the most common criticism doesn't mean that Moose will go on to rule the world if those are fixed. Speaking from experience, the people who complain about something are the ones who wouldn't buy it anyway even if the flaws were fixed. In other words, it's not the flaws keeping them from buying, but their disinterest in buying that leads them to find flaws. So, Moose team, please don't work yourselves too hard optimizing things for people who may or may not convert into customers anyway and don't pay too much mind to the criticism. Everyone, myself included, is a master of the obvious. 99% of what's said by 99% of people is just chatter designed to establish a connection based on shared perception, not any sort of real insight.
So, how about the weather, eh?
-scott
Re:Chillin' a bit here
scrottie on 2009-01-18T22:23:04
By the way, I wrote the original article after fighting with Moose as a dep for a 30 line module that really had no business using it, and was shorter with it removed. Moose became my punching bag for all of the failed deps that had pissed me off recently. I'm going to, in the future, argue for a minimal aesthetic in Perl without using a punching bag, but rather just on merits alone.
-scott
