A recent thread on the Mason users list reminded me of the problems I had grokking Catalyst when I first looked at it. Raymond Wan wrote “I’m skimming over the MVC part and as my system doesn’t use an SQL database, I’m wondering if Catalyst is overkill??” Those of us who know Catalyst know that this question is based on some wrong assumptions, but it’s easy to see why Raymond has those assumptions.

So a few weeks ago I got an infection that’s quite painful to have. The infection is gone but the pain lingers on, and according to my doctor can linger for months. I realized today that I am still exhausted from being sick, as well as being involved in the planning of three major events over the last six months or so - Frozen Perl, my AR group’s fundraising banquet, and our conference this past weekend.

I’ve been thinking about this idea of ruthless pragmatism over the last few days. What is ruthless pragmatism? How can we actually be ruthlessly pragmatic? Do we even want to be? Defining ruthless pragmatism is harder than you might think. The problem is that it’s easy to claim we’re being pragmatic, but I think mostly that consists of acting out our biases. If you are inclined to think that people won’t hear our (animal rights) message, you’ll probably tend towards so-called “direct action”, because you think that intimidation and property damage are the most pragmatic approach.

I’m not trying to pick on pattrice, I promise. In fact, I thought her keynote was thoughtful and thought-provoking, and that means I actually have something to say about it. During her keynote, pattrice stated that meat consumption is at an all time high. I can’t argue with the raw numbers. More animals are being killed for food now than ever in the past. But I’m getting a little tired of hearing this fact quoted without any context.

Update: The first version of this entry was all mixed up with the next entry. That’s now fixed. This past weekend’s TLOV 2009 conference is over, and I have a lot to think about. In particular, I both agreed and disagreed with much of pattrice jones’ keynote on Sunday afternoon. Her keynote outlined an approach to animal rights based on the axiom that “animals exist”. This means that animals are creatures with desires that need to respected right now, as opposed to in some future theoretical sense.

After ranting about dependencies, I started thinking (which is not the same as ranting by any means!). Other systems have long dependency chains, but people don’t complain. Specifically, I’m thinking of Debian, which has great tools for tracking and installing package dependencies. I used the cool debtree tool to create a dependency graph for gimp. Check this monstrosity out! That’s a lot of dependencies! But it isn’t considered a problem, and I don’t think you’ll find anyone out there complaining that gimp’s dependency chain is “too long”.

Dear whiners-about-dependencies, Please stop whining. Recently, there was a thread on Perlmonks which included the quote, “the dependency chain on Moose and MooseX is ’long’.” What is “long” here? Moose really doesn’t have that many dependencies. Also, conflating Moose with a bunch of Moose extensions is just weird. Chris Prather then wrote a blog post explaining why Moose has each dependency. That was nice of him, but I’m not sure addressing the whiners like this is worthwhile.

The Moose docs grant is finished, so I’m going to review what exactly was accomplished, and how it differed from the original grant proposal. I’ll take each section of the original proposal one at a time. Write a set of Moose::Intro docs I ended up calling this documentation Moose::Manual instead, but what was produced is pretty similar to the original plan. The original proposal called for the following sections: Moose::Intro::Attributes Moose::Intro::Subclassing Moose::Intro::MethodModifiers Moose::Intro::MooseObject Moose::Intro::Roles Moose::Intro::Types Moose::Intro::Introspection Moose::Intro::MooseX The end result produced the following:

I actually finished the grant about a week ago, but I’ve been so busy I forgot to say anything here! The last recipe I wrote was a new Basics recipe on subclassing non-Moose classes. The original plan called for a recipe on hooking into Moose’s immutabilization system, but that part of Moose is really nasty, and Yuval Kogman has plans for a major re{factor,write}. There’s really no point is documenting what’s there now.

Working on the Moose and Class::MOP API documentation recently has once again reinforced the importance of writing documentation. Writing docs hugely improves your APIs. Conversely, not writing docs makes it much easier to write really bad APIs. I’m hoping that going forward, all new Moose and Class::MOP work will require API docs for all public APIs. This will help us catch bad designs before they’re released. Here’s some code smells I think docs help catch …