Doozi: Dezi + Moose

I have been working on the project now called Dezi, in one form or another,
since 2005. The actual kick-in-the-pants to make a Product, rather than a Loose Affiliation of Modules, came in an exchange in the comments of a blog post about metacpan.org.

Dezi has gone through several releases in the last few years. Now I'm preparing for a big, new release (0.3.0) that represents (for me) a seismic shift in the way I'm thinking about the product. It has to do with social coding.

Way back when, I started using the Rose family of Perl modules for work. I developed many CPAN modules against the Rose suite. I continue to find the Rose modules well-built, well-documented and very fast. I rarely find a use case that has not already been anticipated.

Here's the thing about Rose: it's mostly a one-man show. John Siracusa conceived of and wrote 99.9% of the code in the Rose namespace. John writes really good code. It's a pleasure to use. It's hard to hack on. It's highly optimized for performance, not hacking. That's ok, since it is full of very extensible features and John is very receptive and responsive to bug reports and feature suggestions. I've been able to contribute a few patches and ideas to the codebase, and count myself fortunate to have done so. Half the CPAN modules I've written are based on or extend the Rose code, and I'm happy to have done that.

Now I'm switching from Rose::Object to Moose. It's a decision several years in the making. Here's the story.

When Moose was first released, back in 2006, I was about five years and three different jobs into my career as a Perl hacker. I had just started using the Rose modules, having selected Rose::DB::Object for a major work project. The RDBO modules were mature and full-featured. In the course of using them I got to know the Rose::Object module upon which RDBO is based. I knew my cognitive capacity and time were both limited, and since Rose::Object was mature, stable and feature-ful -- not to mention very fast, a claim later borne out by benchmarking -- choosing Rose::Object as my object system of choice seemed natural and wise. I didn't invent it (a point in its favor), there were mature projects depending upon it, and Perl luminaries vouched for it. I wrote and released several well-received modules based on Rose::Object, and wrote a Class::Accessor::Fast-like emulator for Rose::Object that I used for other projects, including the primary dependencies for Dezi.

Moose was new at that point, and got a lot of attention. But though it looked interesting, all the reports I read said it was slow, and I knew I didn't have the tuits to learn something new if it wasn't going to perform to the level of the thing I was already using.

Since then Moose has become a pillar of the so-called Modern Perl movement. All the cool kids use it. Every job description (not that there are that many any more for Perl) claims to want experience with Moose. Still, I resisted coding anything significant with it.

Some years passed. Dezi got released. Then, a few months ago, I was starting a new project that I hoped would become the standard Perl interface to a new service I have been shepherding for my $job. I decided I would approach it differently than I have historically: I wanted it to be hacked on, rather than simply used. So I decided to pick an object system that a lot of programmers were already using. I started with Mouse because I understood it to be a faster, lighter weight module with Moose-like syntax. Speed was still paramount to me at that point. I found Mouse easy to pick up and use, and rather enjoyed the elegance of the type constraints and coercion syntax.
Then I ran into a snag: I wanted to use a Moose module that had no Mouse equivalent.
I hopped on to #moose at irc.perl.org and asked about it. I was told to switch to Moo. I tried. It was hard because it required rewriting a bunch of type constraint code. So I decided -- rashly, out of my impatience -- to try Moose instead. It was a single global search-and-replace for s/Mouse/Moose/g. And lo! things kept working as they had before. All my tests passed. And now I had access to the entire Moose ecosystem on CPAN, which, let's be honest, has become a formidable force. I considered that effort a success. It was fun to use, and the performance difference was, truly, a non-issue. The application spends the vast majority of its time on I/O so method speed and start-up time was just not relevant.

That was a new project. I started to think: is it time to switch my existing projects to Moose? I've obviously built up a reputable bunch of modules that depend upon Rose. Why would I switch now? It's not why you think. Moose has not overtaken Rose in terms of performance or some killer feature I couldn't get any other way. No, I'm switching because I'm lonely.

Coding is a solitary exercise. You sit alone in front of the screen and think and think and type and think and delete and think some more. I've broken the Backspace key through repeated use on more than one keyboard. It's a lonely, slogging effort.

And then when you realize you can't solve the problem on your own, you ask for help. You ask your favorite search engine to find you an example of someone else solving a similar problem; you search for error messages you do not recognize; you search for documentation. And then you turn to IRC, that long-in-the-tooth technology we programmers still use to communicate in real time with others like ourselves. The irc.perl.org server hosts dozens of channels dedicated to every facet of the Perl programming community. There's one for #rdbo. And there's one for #moose. When I asked for help on #moose that time, I immediately got several helpful responses, and enjoyed a few jokey exchanges, and in general remembered the good feeling of belonging to a vibrant community that thrums along, working and helping each other. I realized that I had missed that feeling for several years. There are an average of 200 people on #moose at any given time. There are less than ten on #rdbo. That's telling to me.

Do not misunderstand me; I've received great help on #rdbo in the past, and will, I'm sure, in the future. It just doesn't have a critical mass of the Perl community right now, which is a shame, really, since the code is so great. I think the DBIC vs RDBO and Rose vs Moose contrast is a study in how communities form and evolve. With DBIC, Matt Trout made a really conscious effort to code for community over performance. Not that he or John dismiss either strength. It's a question of emphasis.

For me, now, it's not about the merits of the code; it's about the merits of the community, and the energy it gives me to know that others are working through problems similar to my own.

So I've embarked on a large refactoring effort of all the Dezi dependencies, and Dezi itself, to switch from Rose::Object to Moose. I am dubbing this the Doozi release. I've spent the last four weeks working on it, and having a load of fun. I look forward to releasing it, and seeing whether Dezi's new Moose-iness attracts any new blood.

2 Comments

If you are concerned about performance you might want to look at Moo as well. This is another project that is built around a community and really aims to be forward compatible with Moose. The idea is that you can write core stuff in Moo and your users can stick with Moo if they want performance and low dependencies but can also take the full power of Moose if they need it.

jnap

Leave a comment

About karpet

user-pic I blog about Perl. Occasionally.