Well, I thought I was getting better, but I was wrong. Last week my infection seems to have had a resurgence, and I’m not feeling well enough to travel. Yuval Kogman has offered to teach the Moose tutorial at OSCON, so that will still go on, assuming O’Reilly agrees to the switch. I’m still hoping to go to Italy in October. If I’m not recovered by then, I’m just going to have to get a robot body, because this meat sack is not working out so well.

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.