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 …

I’m just inches away from declaring the grant done. Last week, I released new versions of Class::MOP and Moose which feature (mostly) complete API docs. I say mostly because some things are intentionally being left undocumented for now. These are methods with public names (no leading underscore) that I think should be made private, or in a few cases entire classes with really weird APIs that need some rethinking. I think the API docs are done enough to satisfy the grant requirements.

I’ve felt for a while like my current position isn’t a good fit for me. Basically, the way they do development is kind of 1995-centric, and I don’t have any power to change it. I find this very draining. Talking to a friend, he also pointed out that my current job is very isolating. I work from home, and my projects are basically all solo. When I worked at Socialtext, everyone was remote, and so everyone chatted on IRC.