I love pre-modern Perl and so should you, my introduction
My name is David Shultz, I've been working with Perl since the late 1990's where I live in wonderful Portland, Oregon. I'm self taught, I code because I love the challenges and excitement it provides. I got my first job as a programmer working for a small porn company, then a small spam company, financial analysis firm, and finally my current employer of over 11 years, a medium sized data warehousing company. For the last 6 or more years I've worked as a project manager/lead programmer with a small team of really great people. I've worked with a few prominent people in the Perl community, and a few more have graced my employers doors over the years. I've had an amazing time over my years with Perl but not all has been rosy.
A few things have happened over the years both with Perl as a language and with the community itself that has kept me fairly quiet, not anymore. I'm not here to bash anyone or any idea specifically, rather I am here to promote a simpler way. You see I don't love "modern Perl", in fact I kind of hate it. I've been working with Perl long enough to see fads come and go both inside and outside my work.
I will never forget the day I saw my first mixin class added to our shared corporate code base. At first I thought it was an interesting idea, then I found out the greatest feature of a mixin was to hide functions from me, this amazing power was only amplified when combined with multiple layers of inheritance. My current code base is well over 3 million lines of code, mixins haunted my dreams until I banned them from my project roughly six years ago.
Then Moose came along and with it mixins in the form of roles. I've been using a 1.x version of Class::MethodMaker for many, many years but Moose kept creeping up in conversations both online and off with increasing frequency and appreciation. Due to my experience with mixins in the past I decided to take the wait and see approach. Other groups at my company began adding Moose to their projects and it wasn't long before Moose found it's way into our shared corporate code base. This code base is the core of every project at the company, every project but mine. I had severed ties with this shared code base many years previously due to constant incompatible changes being applied from other projects.
I've watched as Moose increased the hardware requirements, the load times of child processes and the verbosity of basic class definitions, I believe I chose wisely to stay away. Then came Mouse, Moo and Any::Moose. I'm not sure the community has really decided what it wants, but I know what I want, Class::MethodMaker version 1.12 from Sept. 12th, 2003. Thank you Martyn J. Pearce for such a simple and functional bit of code, I use it daily, it's worth it's weight in gold as far as I'm concerned.
P5P has done some amazing work over the years, that being said I'd love to see switch/given/when/etc get solidified so I can start using it. Also Perl 6, can't really say anything that many of you don't already know.
I love Perl, more specifically I love Perl 5. I have not been loud, I have not spoken up in public about Perl, even at work I have generally stayed quiet. But no more, beginning with my next post I will write monthly about a topic of interest to myself, likely related to my work using core Perl 5. I'll do my best to provide code samples, explain my thinking, and hopefully provide some examples of earlier work that failed and why. I strongly believe in test driven code, a detailed naming scheme and small concise functions.
All the new features, ideas, modules, etc. are great fun for the community, but it is my opinion that for each of us to increase our skill set and productivity, we must increase our understanding and use of the core language. I do use work from the community. I love the CPAN, but my posts won't be about the latest cool module and how it will change your code. So if you're interested in clean basic code used to solve real business problems with a strong emphasis on data warehousing then I hope you'll stick around.
Lead developer of a large entirely Perl B2B application. Avid Perl enthusiast.
If all you use Moose for is _exactly_ the same things you did in Class::MethodMaker, I can see how it'd end up more verbose. However, Moose adds a number of useful features, such as type checking, predicate methods, etc.
The other benefit of Moose is that it's easy for people to provide Moose extensions. There's a huge ecosystem of Moose-related modules on CPAN. You won't get that with Class::MethodMaker (or pretty much any system that predates Moose).
Yes Moose offers much more then Class::MethodMaker which really just provides easy getter/setter support. I've looked at Moose quite a few times, I also review the code being done by other projects at my company. While it all looks interesting, I generally find that it increases code complexity and system requirements. Moose appears to be the next or POE in that is quickly creating an eco-system of code that only works with itself. I'll continue to post concise code that doesn't require it, or any other framework system.
The funniest part is that POE often gets thrown into the Modern Perl bag, see Task::Kensho::Async
Roles aren’t mixins, for very specific reasons; also, Moo is fairly simple pure-Perl and gives you the simplest and most useful bits of Moose without you having to buy into all of the rest of it (or not yet, if you’d prefer to defer a definite deicison).
(For context, I always liked Moose in principle but always hesitated to actually adopt it, until there was Moo.)
I don’t think you’d be unhappy with either roles or Moo, though whether you want to try them is your call. We can have a discussion about the differences between these newfangled technologies and the ones you know, and about the specifics of your situation, and figure out whether your bad experiences should find themselves unrepeated as I am guessing (e.g. Ovid has written of his experiences using roles to untangle a huge codebase with a massive class hierarchy into something more manageable at scale – not less)…
… assuming you are actually curious.
Though it’s just as well if you aren’t. If what you are doing works for you, there is no need to change it. But in that case just please don’t try to discourage others from trying on these technologies based on bad feelings owed to experiences with distinctly different technologies.
That is funny, I didn't mean to put POE in the "modern" camp so much as to suggest Moose appears to be the next fad after POE.
I am curious, I have worked with Ovid, I know him both personally and professionally, I'll reach out to him on the topic. I remember him writing about Roles via Moose some time ago (while he was with the BBC I think?). I'm very much not interested in discouraging anyone from anything, I'm truly sorry if anything I wrote appeared that way.
I'm not against new or old ways of doing anything. I plan to write about manageable, test driven code with only a clean (recent) Perl installation available.
My biggest push back against Moose was/is that my project only updates hardware about every 2 years, yet we push for better performance and more features every day. We have continually hit our targets on both marks for 9 years in a row. I only wish any team I've seen using Moose could say the same. I'm not saying there aren't teams with that experience, just that I haven't read about or seen any myself.
So I just schooled up on Moose::Manual::Roles and I can't see how they are not exactly like mixins. They play with the namespace differently (cleaner?) as much of Moose does. How do they differ from mixins?
I also looked at Moo again, oddly enough it offers the base of Moose with Moose style syntax, which I use at work provided my by own framework. I might actually use Moo for public code (including examples I'll post about), though does have the same level of verbosity in code that Moose has. I think I'll run some performance tests on Moo, thank you for suggesting I go back and look at it again.
Actually, the community has decided, and it decided on Moo. Mouse diverged from Moose compat too much, and Any::Moose was just a wrapper around Mouse/Moose and has since been deprecated. If you feel Moose is too heavy, then you can use Moo.
Thanks for the reply Stevan, Moo does appear to provide many of the features Moose offers minus the meta stuff. I'm going to play around with it but for posts I'll stick to the core.
Compile-time collision checks, basically, along with method renaming. So unlike with mixins, and unlike with inheritance – multiple inheritance especially –, you are alerted when you do something that will break.
I am trying to compile Ovid’s posts but it’s turning out to be surprisingly difficult because, as I finally figured out, they were made back on use.perl.org (wow, I had blanked out that that thing even existed…), which has become the Perl community equivalent of the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying “Beware of The Leopard”. I intend to have another sift, but I’m leaving that link here anyway in case I never get around to it.
I will highlight his following entries, though:
They seem to be the meat of the matter, though he wrote plenty more about it during that 2009 period (while at the BBC, yes, exactly).
@David, I totally agree, I use core-only functions/modules and trying avoid adding extra dependencies without very, very good reason.
And it works perfectly.
Second language, that I use is Ruby (with Rails), so I know what Moo* and other modern stuff can bring, and I just don't want it in Perl,
it works without it just fine.
I would like to cast my vote in favor of what David Shultz is saying. I have not seen any modern perl enabling module actually solve a problem I was having. I am not completely opposed to Moo. However, if your module uses Moose, your module is almost automatically banned from our systems. Actually if you use most modules and even some frameworks grouped under the term modern perl, they are discouraged from being in our codebase.
We maintain a large code base with several hundred front end applications and several hundred backend libraries. We have perl daemons, and mod_perl and good old cgi. Our applications are written to be perfectly responsive even under boring cgi.
We have one daemon that does payment processing that requires BOP code that choose to use Moose. Guess which daemon takes 3-5 seconds to reload. Guess which library takes 3-5 seconds just to check to see if it compiles.
Here's my decision tree:
If you are the only one developing the code, use whatever makes you more comfortable.
If you have an enterprise-level system and need to coordinate a lot of developers, use Moose/Moo as functionality dictates.
If you are in between, size-wise, you'll have to balance execution speed vs development time/talent.
If it's a CPAN module that's self-contained, use core as much as possible. That way the dependency chain for installation is not overbearing.
If it's a CPAN module that's meant to be extended by the developer, use Moose/Moo as functionality dictates.
If you want to stick with Class::MethodMaker, that's fine. However, when we (boutique financial company) went to 5.10 (from 5.6 (ugh!) in 2009), we went to Moose, away from C::MM, because I found that using arrays and hashes in C:MM required too much "thinking"; the list/scalar context determination needed to be helped along quite a bit. It's been 13-8 = 5 years since I last worked with C:MM however; my recollection might be off, so take that analysis with a gain of salt.
I'm completely with you Matthew, I agree that each person/team should pick the tools they are comfortable with and knowledgeable about.
I haven't had any issues with C::MM myself in relation to list vs scalar context of arrays but that doesn't mean it's not an issue for many others.
My primary goal is to blog about current solutions to current problems without Moo(se), not because there is anything wrong with Moo(se), simply that Moo(se) is far from the only way to solve these problems. Moo(se) already gets more then it's own time in the sun, I just want to remind people that many of use are doing just fine without it.
This evokes a comment in the Camel book I've read years ago: you could be speaking baby perl or modern/advanced perl, but in the end you're still speaking perl. I think the modern perl "movement" isn't so much a movement to change the way we use perl but rather the way we think with perl. Like natural language, perl isn't so big on syntax or language extension, but on nuance and overall "whipupititude" on solving the problems concerned; the way solutions have been thought may have changed, but the way we express it in the language we love is largely unchanged.
If it's a daemon, expected to run for days (or weeks, or months, or even years), then a 3-5 second start up time is hardly much of a penalty to pay. In fact, 30-50 seconds would probably be tolerable. (And still faster than Tomcat!)
Moose takes a while to get started, but once it's running it tends to be very fast and pretty solid. (Much like an actual moose.)
Moose's constructors and accessors are generally faster than any you'd write by hand. (Mouse's even more so, thanks to lots of crazy XS.)