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.

16 Comments

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

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.

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.

I just schooled up on Moose::Manual::Roles and I can't see how they are not exactly like mixins.

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:

  1. Alternatives to Inheritance
  2. Role Oriented Programming
  3. Tips For Converting Base Classes Into Roles

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.

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

Leave a comment

About David Shultz

user-pic Lead developer of a large entirely Perl B2B application. Avid Perl enthusiast.