Comments on: Moose or No Moose http://perlhacks.com/2009/09/moose-or-no-moose/ Just another Perl Hacker's blog Thu, 24 May 2012 15:20:39 +0000 hourly 1 http://wordpress.org/?v=3.3.2 By: tomás zerolo http://perlhacks.com/2009/09/moose-or-no-moose/#comment-2804 tomás zerolo Fri, 02 Sep 2011 11:41:39 +0000 http://perlhacks.com/?p=21#comment-2804 Just for the record. I'm in the (painful) process of deMoosifying XML::Schematron. I don't get all that "coolness" which just introduces a huge list of dependencies (in my case the app is running on an oldish platform and just the prospect of forcing the customer to keep an eye on 7-ish big Perl packages is... beyond disgusting). 700K of Moose just for 80K of packages? Thanks, but no thanks. Just for the record. I’m in the (painful) process of deMoosifying XML::Schematron.

I don’t get all that “coolness” which just introduces a huge list of dependencies (in my case the app is running on an oldish platform and just the prospect of forcing the customer to keep an eye on 7-ish big Perl packages is… beyond disgusting).

700K of Moose just for 80K of packages? Thanks, but no thanks.

]]> By: screwdriver http://perlhacks.com/2009/09/moose-or-no-moose/#comment-2502 screwdriver Fri, 11 Mar 2011 20:46:31 +0000 http://perlhacks.com/?p=21#comment-2502 A Moose is just a crap for people unable to write OO code in Perl. Stupid scrutiny, boring cliche of oo in pure Perl. Just more mess .. for stupid ugly perl teennie boys. A Moose is just a crap for people unable to write OO code in Perl. Stupid scrutiny, boring cliche of oo in pure Perl. Just more mess .. for stupid ugly perl teennie boys.

]]> By: https://www.google.com/accounts/o8/id?id=AItOawnRCemucdk5uPgv8O1VpoGahSqHo4hc2Rw http://perlhacks.com/2009/09/moose-or-no-moose/#comment-40 https://www.google.com/accounts/o8/id?id=AItOawnRCemucdk5uPgv8O1VpoGahSqHo4hc2Rw Tue, 01 Dec 2009 12:46:26 +0000 http://perlhacks.com/?p=21#comment-40 I've read all the arguments and I am still thinking about. I discovered this blog post about a month ago, decided to come back after some time, now I am working on my own modules. Being a maintainer for the package collection around an OS I appreciate the use of Moose in any way. Even if it's not that fast as a specialized perlish version of some routines it delivers a solid and stable framework for oop in Perl. I think this might lead into a lower rate of bugfix releases of the modules you work on. Custom argument and type checking of constructors seems to be leading into bugs fast, Moose provides handy methods for it. As for your module Array::Compare I think Moose is still the right way to go, even if a serious performance hit might strike some of the users. Forking it and delivering a tiny version by someone (as already suggested) might not be the best way of dealing with this problem: it requires all the depended software to be changed and being re-released just as a key dependency has changed. I think API compatibilty is the highest good in the first place, which can be easily done - either in Moose or not. I just saw that it's still using Moose, good choice imho. I’ve read all the arguments and I am still thinking about. I discovered this blog post about a month ago, decided to come back after some time, now I am working on my own modules.
Being a maintainer for the package collection around an OS I appreciate the use of Moose in any way. Even if it’s not that fast as a specialized perlish version of some routines it delivers a solid and stable framework for oop in Perl. I think this might lead into a lower rate of bugfix releases of the modules you work on.
Custom argument and type checking of constructors seems to be leading into bugs fast, Moose provides handy methods for it.
As for your module Array::Compare I think Moose is still the right way to go, even if a serious performance hit might strike some of the users. Forking it and delivering a tiny version by someone (as already suggested) might not be the best way of dealing with this problem: it requires all the depended software to be changed and being re-released just as a key dependency has changed.
I think API compatibilty is the highest good in the first place, which can be easily done – either in Moose or not. I just saw that it’s still using Moose, good choice imho.

]]> By: csjewell.comyr.com http://perlhacks.com/2009/09/moose-or-no-moose/#comment-39 csjewell.comyr.com Sat, 12 Sep 2009 17:34:52 +0000 http://perlhacks.com/?p=21#comment-39 Well, I use Moose in a distribution [Perl-Dist-WiX] that's basically a command-line program [perldist] that wraps around 30 modules for ease of use and maintenance. It also takes between 30 minutes and 6 hours to run, depending on what you pass it, how fast your machine and hard drive are, and what subclasses you ask it to use. (I'm thinking a Perl-Dist-Padre build on my slow laptop without compiling a .par of Alien::wxWidgets first- but you get the idea.) At that point, 2 sec. added to the startup time for a command-line program is not an issue, and if they improve that, it's just frosting on the cake! Well, I use Moose in a distribution [Perl-Dist-WiX] that’s basically a command-line program [perldist] that wraps around 30 modules for ease of use and maintenance. It also takes between 30 minutes and 6 hours to run, depending on what you pass it, how fast your machine and hard drive are, and what subclasses you ask it to use. (I’m thinking a Perl-Dist-Padre build on my slow laptop without compiling a .par of Alien::wxWidgets first- but you get the idea.)
At that point, 2 sec. added to the startup time for a command-line program is not an issue, and if they improve that, it’s just frosting on the cake!

]]> By: http://openid.aol.com/sid2burn http://perlhacks.com/2009/09/moose-or-no-moose/#comment-38 http://openid.aol.com/sid2burn Wed, 02 Sep 2009 11:24:50 +0000 http://perlhacks.com/?p=21#comment-38 If you have already written a CPAN Module, i would recommend that you instead of switching to Moose you should write an Moosified version. Array::Compare::Moose. For completly new Modules i would not hesitate to use Moose from the beginning. And for the problem with Moose and loading time. Primary it is not a problem from Moose, it is more a problem from perl. Because it always recompile everything instead to cache it, but okay we have it, and we must leave with it. But primary the loading problem is only for CLI Programs that have a short runtime. If you have something like "sed" or "grep" that needs five or four seconds to load that would be annoyed. But for persistent programs i didn't care if the starting just needs some seconds to load. And for Padre that i use myself. I start Padre one time, and then the program runs the whole day. Hey Guys, i really don't care if startup is 2 secods faster. Even Firefox and a lot of others programs that i use have a longer start time then Padre, so i really don't see the problem here. And the other thing, to reduce startup time when a programm gets called often the it is better to use some persistent thing. For this there even exists some blog entry from Jonathan Rockway that describes it: <a href="http://blog.jrock.us/articles/App::Persistent.pod" rel="nofollow">http://blog.jrock.us/articles/App::Persistent.pod</a> If you have already written a CPAN Module, i would recommend that you instead of switching to Moose you should write an Moosified version. Array::Compare::Moose.
For completly new Modules i would not hesitate to use Moose from the beginning.
And for the problem with Moose and loading time. Primary it is not a problem from Moose, it is more a problem from perl. Because it always recompile everything instead to cache it, but okay we have it, and we must leave with it.
But primary the loading problem is only for CLI Programs that have a short runtime. If you have something like “sed” or “grep” that needs five or four seconds to load that would be annoyed. But for persistent programs i didn’t care if the starting just needs some seconds to load.
And for Padre that i use myself. I start Padre one time, and then the program runs the whole day. Hey Guys, i really don’t care if startup is 2 secods faster. Even Firefox and a lot of others programs that i use have a longer start time then Padre, so i really don’t see the problem here.
And the other thing, to reduce startup time when a programm gets called often the it is better to use some persistent thing. For this there even exists some blog entry from Jonathan Rockway that describes it:
http://blog.jrock.us/articles/App::Persistent.pod

]]> By: http://www.stripey.com/smylers/ http://perlhacks.com/2009/09/moose-or-no-moose/#comment-37 http://www.stripey.com/smylers/ Wed, 02 Sep 2009 11:01:55 +0000 http://perlhacks.com/?p=21#comment-37 Moose's developers seem to think it shouldn't be used for command-line programs. I've seen several Moose-related talks at conferences (including Piers's excellent <a href="http://yapceurope2009.org/ye2009/talk/1802" rel="nofollow">MooseX::Declare talk</a> at Yapc Europe this year, which really made me want to use it). But at all the talks given by Moose developers they have specifically said Moose has a significant start-up cost, so is only recommended for persistent environments. Much of the stuff I write has a command-line interface, and this has been sufficient to put me off Moose so far. It's really irritating for generic libraries which you know <em>mostly</em> will be used in a mod_perl app or whatever and the command-line use is rare; the minority case appears to be dictating the overall behaviour, which doesn't seem right. But a delay of even half a second on a command can be enough to turn it from being a joy to use to an irritant. To those who claim Moose is usable in command-line commands, please can you get Moose developers to stop saying otherwise, cos it's hard not to take their claims seriously. For a new Cpan module if you use Moose you're potentially restricting the scenarios in which it can be used. That's fine — by definition you're doing that anyway in all sorts of ways, by deciding the scope of your module. Anybody who's needs aren't met by your module simply doesn't use your module. However for an existing Cpan module, switching to Moose may be making it no longer usable for some users whose needs were met by the previous version. That's probably something you want do avoid doing, especially since it isn't straightforward for users to stick at a particular old release of a Cpan module. Adding Moose to an existing module is much more likely to cause upset than using it in new code. Moose’s developers seem to think it shouldn’t be used for command-line programs.
I’ve seen several Moose-related talks at conferences (including Piers’s excellent MooseX::Declare talk at Yapc Europe this year, which really made me want to use it). But at all the talks given by Moose developers they have specifically said Moose has a significant start-up cost, so is only recommended for persistent environments.
Much of the stuff I write has a command-line interface, and this has been sufficient to put me off Moose so far. It’s really irritating for generic libraries which you know mostly will be used in a mod_perl app or whatever and the command-line use is rare; the minority case appears to be dictating the overall behaviour, which doesn’t seem right. But a delay of even half a second on a command can be enough to turn it from being a joy to use to an irritant.
To those who claim Moose is usable in command-line commands, please can you get Moose developers to stop saying otherwise, cos it’s hard not to take their claims seriously.
For a new Cpan module if you use Moose you’re potentially restricting the scenarios in which it can be used. That’s fine — by definition you’re doing that anyway in all sorts of ways, by deciding the scope of your module. Anybody who’s needs aren’t met by your module simply doesn’t use your module.
However for an existing Cpan module, switching to Moose may be making it no longer usable for some users whose needs were met by the previous version. That’s probably something you want do avoid doing, especially since it isn’t straightforward for users to stick at a particular old release of a Cpan module. Adding Moose to an existing module is much more likely to cause upset than using it in new code.

]]> By: nomaddervish.myopenid.com http://perlhacks.com/2009/09/moose-or-no-moose/#comment-36 nomaddervish.myopenid.com Wed, 02 Sep 2009 10:37:39 +0000 http://perlhacks.com/?p=21#comment-36 <i>The reality of the current Perl 5 programming situation is that if you want to do OO right, you need to be using Moose.</i> Define "do OO right". Any answer containing explicit reference to Moose will be disqualified. ("You must use Moose to do OO right." + "Doing OO right is defined as using Moose." = "You must use Moose to use Moose", which isn't a terribly meaningful statement.) <i>So don't worry about the people complaining to you about using Moose. Their priorities are not necessarily the same as yours. (Most people want to write clean, functional code.</i> False dichotomy. I am convinced that it is possible to write clean, functional code without using Moose. I suspect you would agree, as disagreeing would imply a belief that absolutely no clean, functional Perl code existed prior to the creation of Moose. Don't get me wrong - Moose is a great tool and extremely useful in a wide variety of cases. But it is not The One True Way To Write Perl. Remember TIMTOWTDI? The reality of the current Perl 5 programming situation is that if you want to do OO right, you need to be using Moose.
Define “do OO right”. Any answer containing explicit reference to Moose will be disqualified. (“You must use Moose to do OO right.” + “Doing OO right is defined as using Moose.” = “You must use Moose to use Moose”, which isn’t a terribly meaningful statement.)
So don’t worry about the people complaining to you about using Moose. Their priorities are not necessarily the same as yours. (Most people want to write clean, functional code.
False dichotomy. I am convinced that it is possible to write clean, functional code without using Moose. I suspect you would agree, as disagreeing would imply a belief that absolutely no clean, functional Perl code existed prior to the creation of Moose.
Don’t get me wrong – Moose is a great tool and extremely useful in a wide variety of cases. But it is not The One True Way To Write Perl. Remember TIMTOWTDI?

]]> By: jrock.us http://perlhacks.com/2009/09/moose-or-no-moose/#comment-35 jrock.us Wed, 02 Sep 2009 08:36:41 +0000 http://perlhacks.com/?p=21#comment-35 I think your Moose-using modules look pretty nice. I would not hesitate to introduce one as a dependency to my project. (Could you have not used Moose? Sure. But you could have also not written the code at all, or you could have written it in Brainfuck, or whatever. "Coulda, shoulda, woulda...") The reality of the current Perl 5 programming situation is that if you want to do OO right, you need to be using Moose. Correctness comes with a small performance hit. (But if you care about absolute performance, why are you writing your performance-critical code in a language that is 50x slower than, say, Haskell?) Gabor and Adam mention that Moose is too big a dependency for Padre, but honestly, by not using Moose, they are severely limiting the extension possibilities. Nobody writes Eclipse extensions because the extension API is too brittle. It is just plain hard to use. Sure, there are a few token extensions... but if you (as a user) ever wonder "can I do foo", you probably can't, and writing "foo" yourself is going to take the rest of the month. Emacs, on the other hand, ships its own programming language, compiles, runtime, and virtual machine, just so you can say "M-: (next-line)". (Overengineering!!!1111!) Because of this, though, extending Emacs is a joy. Writing valuable macros takes just a few minutes. Writing complex extensions -- support for new programming languages, project management functionality, mail readers, IRC clients, ... -- is similarly easy. The end result is that the source tree contains 2 million lines of (optional) Lisp extensions! So basically, a big dependency made it easy to implement new features, and people did. The associated startup time and memory costs just don't matter -- the program itself is too useful for anyone to get too upset. (And BTW, emacs23 has multi-tty support, which makes it start instantly. Just like App::Persistent for Perl.) For me, a user of a text editor, functionality is the most important thing. So what if it takes 5 seconds to start up? I only do that once every 3 months. (BTW, for the opposite perspective, look at minimalist "vimscript". Yeah, you can kind of script the editor with it, but it is nowhere near as powerful as Emacs Lisp. The result is that vim starts fast, but users have to live with compromised productivity inside the editor. That makes me sad.) So don't worry about the people complaining to you about using Moose. Their priorities are not necessarily the same as yours. (Most people want to write clean, functional code. Padre is aiming for fast startup times and low memory usage at the cost of cleanliness and functionality. To each their own.) Anyway, sorry that this became a long rant, but basically -- you are writing good code, and most people would rather have a well-implemented module that adds 0.05 seconds to their app startup time than having a flaky-but-fast module, or nothing at all. Don't worry about complaints on rt.cpan. If Mark and Adam can't use Array::Compare because it uses Moose, that is their problem, not yours. I think your Moose-using modules look pretty nice. I would not hesitate to introduce one as a dependency to my project. (Could you have not used Moose? Sure. But you could have also not written the code at all, or you could have written it in Brainfuck, or whatever. “Coulda, shoulda, woulda…”)
The reality of the current Perl 5 programming situation is that if you want to do OO right, you need to be using Moose. Correctness comes with a small performance hit. (But if you care about absolute performance, why are you writing your performance-critical code in a language that is 50x slower than, say, Haskell?)
Gabor and Adam mention that Moose is too big a dependency for Padre, but honestly, by not using Moose, they are severely limiting the extension possibilities. Nobody writes Eclipse extensions because the extension API is too brittle. It is just plain hard to use. Sure, there are a few token extensions… but if you (as a user) ever wonder “can I do foo”, you probably can’t, and writing “foo” yourself is going to take the rest of the month.
Emacs, on the other hand, ships its own programming language, compiles, runtime, and virtual machine, just so you can say “M-: (next-line)”. (Overengineering!!!1111!) Because of this, though, extending Emacs is a joy. Writing valuable macros takes just a few minutes. Writing complex extensions — support for new programming languages, project management functionality, mail readers, IRC clients, … — is similarly easy. The end result is that the source tree contains 2 million lines of (optional) Lisp extensions!
So basically, a big dependency made it easy to implement new features, and people did. The associated startup time and memory costs just don’t matter — the program itself is too useful for anyone to get too upset. (And BTW, emacs23 has multi-tty support, which makes it start instantly. Just like App::Persistent for Perl.)
For me, a user of a text editor, functionality is the most important thing. So what if it takes 5 seconds to start up? I only do that once every 3 months.
(BTW, for the opposite perspective, look at minimalist “vimscript”. Yeah, you can kind of script the editor with it, but it is nowhere near as powerful as Emacs Lisp. The result is that vim starts fast, but users have to live with compromised productivity inside the editor. That makes me sad.)
So don’t worry about the people complaining to you about using Moose. Their priorities are not necessarily the same as yours. (Most people want to write clean, functional code. Padre is aiming for fast startup times and low memory usage at the cost of cleanliness and functionality. To each their own.)
Anyway, sorry that this became a long rant, but basically — you are writing good code, and most people would rather have a well-implemented module that adds 0.05 seconds to their app startup time than having a flaky-but-fast module, or nothing at all. Don’t worry about complaints on rt.cpan. If Mark and Adam can’t use Array::Compare because it uses Moose, that is their problem, not yours.

]]> By: frioux http://perlhacks.com/2009/09/moose-or-no-moose/#comment-34 frioux Tue, 01 Sep 2009 22:38:05 +0000 http://perlhacks.com/?p=21#comment-34 Mouse is ghetto, even the authors say not to use it. There are plans (I'll try to blog about them tonight) to make basic Moose usage much faster. That means that as long as you are just using attributes, you should be fine, which a lot of these basic things are. So I'd say stick with Moose. We'll get it fast for you :-) Mouse is ghetto, even the authors say not to use it. There are plans (I’ll try to blog about them tonight) to make basic Moose usage much faster. That means that as long as you are just using attributes, you should be fine, which a lot of these basic things are. So I’d say stick with Moose. We’ll get it fast for you :-)

]]> By: chris.prather.org http://perlhacks.com/2009/09/moose-or-no-moose/#comment-33 chris.prather.org Tue, 01 Sep 2009 20:18:07 +0000 http://perlhacks.com/?p=21#comment-33 Going from the Array::Compare::Tiny idea one of the interesting things I've seen is Net::Twitter. When Marc Mims took over he ported the entire thing to Moose to ease maintenance since the Twitter API can be a ... complicated challenge ... to keep up with. However he knew that people would complain (and they did almost immediately) with the new overhead. Thus he worked out a solution where he generates Net::Twitter::Lite from the Moose code. This may not be the option for you, but was an interesting take on the "What do do with the Moose?" problem. Going from the Array::Compare::Tiny idea one of the interesting things I’ve seen is Net::Twitter. When Marc Mims took over he ported the entire thing to Moose to ease maintenance since the Twitter API can be a … complicated challenge … to keep up with. However he knew that people would complain (and they did almost immediately) with the new overhead. Thus he worked out a solution where he generates Net::Twitter::Lite from the Moose code.
This may not be the option for you, but was an interesting take on the “What do do with the Moose?” problem.

]]>