Dave Cross also left a comment on my last blog post clarifying the relationship between his Array::Compare module and Test::Warn. Seems that the author of Test::Warn actually removed the usage of Array::Compare in a dev release several months ago, but simply forgot to remove it from the META.yml dependency listing. While I still think it is important to look downstream before you port to Moose, this clarification got me thinking as well.
Next comes Jonathan Rockway and his emacs fetish. Jonathan left a comment on Dave's blog which if you didn't know Jonathan, might be mistaken for an attempt to ignite the eternal Emacs vs. VI flamewar. But if you look beyond the emacs fanboi-ness of the comment you will see that Jonathan is (as usual) really making an excellent point about Padre, its extensibility as an editor, its dependencies and the choices its authors are making in relation to those things. This got me thinking about what Moose might be able to bring to the Parde party, good or bad.
So, now for my thoughts ...
To answer Chris's question, there are at least the two people who commented in the RT bug. The first is Adam Kennedy, who loves all things fast and tiny and has long complained about Moose's appetite for CPU and memory. And the second is Mark Stosberg who is a big advocate of vanilla CGI on which he and I have long disagreed. It is not surprising that neither of them like Moose. Are they representative of some kind of majority? Or just religious extremists worshipping at the altar of slim computing? It is hard to say, they both have valid concerns, but history and trends are pretty clear in how bloated software and ever improving hardware are constantly pushing one another forward (Moore's Law FTW).
So, as I said before, I agree-to-disagree with Adam and on his points, but the more I think about it, I think perhaps he is just knee-jerking here and possibly even using RT in anger. In the RT bug he says
This adds a huge amount of additional dependencies
Now sure this is true in relation to Array::Compare, but we all know that Adam is really talking about Padre. This is a little ridiculous considering Moose (on 5.10.0) has only 21 depenencies, 6 of which are core modules and has a 92% chance of installing (it would be 100%, but List::MoreUtils is dragging us down). While Padre (also on 5.10.0) has 104 dependencies, 32 of which are core modules and only has a 24% chance of installing (and requires a threaded Perl as well). So really how many dependencies would Moose add to Padre? Of the non-core dependencies they share 5 dependencies, so 21 - 6 core - 5 shared = 10, which when added to Padre's 62 non-core deps brings the grand total to 72.
Now, you might say "Wait a minute, thats a non-trivial amount of additional dependencies", and in fact you would be correct. However, the likelyhood that Moose is already installed is fairly high and growing by the day as it's popularity increases and already popular modules like Catalyst start using it. You see, Moose is not like other CPAN modules which simply provide a specific feature for a specific need, but instead is a tool to extend the language itself and which you use to create other CPAN modules. Because of this, the chance of having Moose already installed, either directly or because you install one of the approximately 600+ modules that use it, is pretty high.
Adam's next point about startup time is valid, this has long been an issue with Moose. We have made great strides on this issue over the years, but there is still a ways to go. How much this truly affects Padre though is debatable, as Jonathan Rockway pointed out, how many times a day/week/month are you really going to be starting up your text editor? Is startup time for a featureful IDE with possibly many plugins really that big of a deal? It certainly hasn't seemed to slow down the adoption for things like Eclipse.
And finally, to Adam's last comment ...
If this can't be fixed, we're going to need to remove Array::Compare (and everything that uses it) from Padre
this was actually the part that concerned me most because of what Adam is saying to all the authors of Padre's 62 non-core dependencies. While I do believe CPAN developers should look downstream before adding dependencies in the spirit of being a good neighbor, I think it is a little unreasonable for those upstream to dictate what is and is not an acceptable dependency.
Sure Dave's Array::Compare is a straightforward module and the benefits Moose brought to it were fairly minimal. But there are some pretty complex modules in Padre's dependency list, many of which could probably benefit greatly from Moose. And what about Padre plugins? Are they allowed to use Moose? What if they become popular plugins and the Padre folks want to merge them into the core? Do they have to shed the Moose before being allowed in? Where does this insanity end!?!?!
See, Moose is growing in popularity a lot lately. The number of CPAN modules that use Moose have been growing at a very steady pace. The #moose@irc.perl.org channel regularly has over 200 people in it. If you read the Perl Ironman blogs, you have no doubt seen a lot of Moose there lately. The number of Moose related questions on Perlmonks has been increasing lately (I should know I answer many of them). There were 16 talks at YAPC::NA this year tagged with Moose (including a 6 hour Moose course) which made Moose one of the largest tags in the cloud. This was followed by 7 talks at YAPC::EU this year.There will be approx 5 or so talks at the upcoming YAPC::Asia (including the Moose course again given by Sartak). Dave Rolsky will be giving a Moose course at the Italian Perl Workshop. Moose is also central to the EPO's extended core effort. We even get a fair amount of twitter traffic (for whatever that is worth).
Because of this, I really think Moose has proved itself not to be just a fad, especially considering this momentum has been steadily growing over 3 and a half years now. While it might be reasonable of Adam to request upstream deps not use Moose right now, how much longer before this becomes a real problem for Padre? Will the culture of NIH set in? Should Padre embrace the Moose future now? Has anyone even benchmarked/profiled how much of an impact Moose would have on Padre?
So Internets, what do you think?
I think this and all the other posts about Moose are trying to rationalize away and excuse slow and bloated software.
ReplyDeleteI think people need to stop and really think about what value are they truly getting from Moose and whether it's really needed for each individual project.
Just when the rest of the world seems to have finally woken up to the fact that OOP is not the most important thing about programming, the Perl community is suddenly giving OOP far more credence than it deserves.
So are we going to now be awash in CPAN modules that download half of CPAN just to parse a URI? Is it going to be necessary to have umpteen MooseX extensions to make an FTP connection? The dismissal of those who are trying to hold back the floodgates of bloat as if they are somehow luddites for doing so is going to bite us all in the ass. And what's so hard about blessing a hash anyway?
I'm not saying don't use Moose...if you're doing business software, or something that's really going to benefit. Seriously though, since when have library modules been in the business off OOPifying everything? Maybe in corporateville but not where the real work gets done.
It's death by a thousand cuts if it becomes standard for CPAN modules to get on the gravy-bloat train.
The luddites are the ones who think OOP is the most important thing since sliced bread. It's not 2004 anymore!
Some good discussion about OOP on Lambda The Ultimate:
ReplyDeletehttp://lambda-the-ultimate.org/node/3265#comment-48063
This "half of CPAN" meme is getting seriously tiresome. List::MoreUtils is used by a ridiculous number of things already. Sub::Name, Task::Weaken, MRO::Compat, and Devel::GlobalDestruction are *necessary* in order to work around dumb edge cases in perl itself (and Task::Weaken isn't even an actual module!). And Sub::Exporter makes the task of writing Moose-using exporter modules (which is how most Moose extensions are loaded) actually reasonable, instead of painful like with Exporter.
ReplyDeleteThese are the *only* direct dependencies that Moose has. Even counting recursive dependencies, this is only 12 modules (9 on perl 5.10), and every one of them other than List::MoreUtils has 0 test failures. Any non-trivial CPAN-using project in perl is going to have enough dependencies that this shouldn't be an issue (and a lot of those projects will have overlapping dependencies here too). There are some valid criticisms of Moose (that are known, and are actively being worked on), but the dependency chain really isn't one of them.
As for "what's so hard about blessing a hash anyway", perl is very good about avoiding necessary boilerplate in other parts of the language, and having an object system that similarly avoids that makes it much easier to attract new programmers... sure, blessing a hash is a simple concept for *you*, who already knows perl, but is a distinct step backwards from other language options out there. If we stop attracting new users, perl really will be dead.
@doyster:
ReplyDeleteNext time I won't say "half of CPAN" so that you don't get the chance to base your entire rebuttal on one line.
The core problem of Moose startup time as been the same since the very first time I tried it when it first came out.
And bloat is bloat. Arguing that it's okay for Padre to be slow because Eclipse is slow is about the most stupid thing I've ever heard in a Perl debate. Justifying Perl bloat with Java bloat?!?? LOL, that's just retarded.
And what about this wasteful time spent worrying about OOP for library modules? People are acting as if this Role thing is the only want to get some really very simple things done. Padre is right to go for fast startup time over the gooey slime of Eclipse-style bloat.
This comment has been removed by a blog administrator.
ReplyDelete@marcus : LtU is *not* the place to see good discussion on OOP, as it is full of FP fanboys (I should know, I am one myself). Sure they are smart people, but they are one small, very opinionated portion of the overall programming community for whom often times form is more important then function.
ReplyDeleteAnd your "the rest of the world seems to have finally woken up to the fact that OOP is not the most important thing about programming" comment is just totally wrong.
The reality is that the world has *finally* woken up to how cool and useful FP is, and how much more powerful a multi-paradigm language like Perl is then a purist single-paradigm language like Java, etc. Perl is a powerful and flexible multi-paradigm language, but until Moose (or rather until Perl 6 and Moose stealing good ideas from Perl 6) Perl had a pretty poor OO component in it's toolbox.
But anyway, it is pretty clear your just spreading FUD and looking for a fight, so I am done with this.
@marcus: Your ignorance is showing again with the "The core problem of Moose startup time as been the same since the very first time I tried it when it first came out" line. This only goes to show that your trolling and have no clue what you are talking about. Any more comments from you will be deleted.
ReplyDelete@marcus: Wow, "Arguing that it's okay for Padre to be slow because Eclipse is slow is about the most stupid thing I've ever heard in a Perl debate" you missed that point pretty badly. Eclipse is slow to load because it has a lot of very useful features, which take a long time to initialize and load. The same is true of almost all other IDEs out there as well. To many people this in an acceptable trade off for a program they probably only start up at most once a day.
ReplyDeleteHi Stevan, yeah - it does seem like Marcus is trying to pickup a fight - but please don't silence him. It needs to go somewhere. I am sure many people will chime in soon with support for you.
ReplyDeleteAnd yeah - I don't mind if you delete this comment for going too much meta.
I'm not trying to pick a fight. You rebutted the points, but censoring them?
ReplyDeleteAre you saying that Moose has not always had slow startup time? I'm strugeling to understand how this statement of fact from my own experience and well recognized in discussions of moose is a demonstration of ignorance.
I care about this topic. You asked for feedback. This is feedback. Sorry if it's rougher than you expected, but it's not a troll.
@marcus: I won't censor comments, but trolling I will because it is just a waste of everyones time. I don't mind rough feedback either, as long as it is has some value and isn't just clear attempts to start flamewars (aka - trolling).
ReplyDeleteBut your "half of cpan" and "umpteen MooseX modules" comments are just trolling. The OO hating is seriously misinformed, but you are entitled your opinion on that. As for the startup time comment, this too is way off base.
"Are you saying that Moose has not always had slow startup time?". Not at all, I am saying that it's startup time has greatly improved over the past 3.5 years, and recently speed up by almost 20% thanks to gfx.Your comment was "The core problem of Moose startup time as been the same since the very first time I tried it when it first came out", which clearly is not true and completely ignores/dismisses all the work people have done to fix this problem.
Look, I am happy to have a discussion with you, but you need to slow down and check your facts more and try not to just spew misinformation and FUD.
I'm trying to avoid having to look too closely at CPAN modules to see if they are too slow for my purpose. I've got a basic expectation of speed with a lot of modules, and I'm hearing that many of considering a switch to use something that is known to slow down the startup.
ReplyDeleteThis startup time issue has a very real effect on the usefulness of those modules to me, because I often have to write daemons that spawn quickly, as well as command line apps.
I wrote detailed points, you can decide to label that as starting a flamewar or trolling if you want, but from my perspective I'm seeing danger ahead and I want to avoid that danger. And thus my detailed and emphatic comments.
@marcus
ReplyDeleteTo start with, I don't think you really need to worry that people will be porting older, long relied upon CPAN modules to Moose. What Dave did was a personal experiment and not the start of a trend.
In my previous post you will note that I discouraged this practice for exactly the reasons you cite. People should always look downstream before making big changes to modules, we have the means to do that through CPANTS now.
You can rest easy, there is no danger ahead only blue skies, rainbows, bunny rabbits and unicorns (the Moose are optional).
FWIW, I've found this comment thread thoroughly helpful in presenting some of the dynamics at play within different Perl project, and programming in general. Viva healthy debate!
ReplyDelete@marcus: I apologize, it seems you were correct that Moose startup time has not significantly better over time. See my latest blog post for more details.
ReplyDeleteMaybe Marcus's first post was rougher than it should, hence immediately dismissed as trolling or flamebait. But when I read it, I focused on this part:
ReplyDelete"So are we going to now be awash in CPAN modules that download half of CPAN just to parse a URI? Is it going to be necessary to have umpteen MooseX extensions to make an FTP connection? The dismissal of those who are trying to hold back the floodgates of bloat as if they are somehow luddites for doing so is going to bite us all in the ass. And what's so hard about blessing a hash anyway?"
Except for the "floodgates of bloat" part (which is just silly), I have to agree with his point. Use Moose. But only when it actually aggregates simplicity and flexibility to your code. Not because it's the new hype. Moose (and OOP, where this conversation was leading to) let's you do powerful stuff. Yet, before using it, make sure you actually need it.
Still, as Stevan said, I too think we shouldn't loose any sleep over people porting old, long relied upon (or plain simple) CPAN modules to Moose - and this should be discouraged. Let's just KISS, do OOP when OOP is needed, and use Moose whenever it aggregates value to our code.