Digging Up Bones:
The Legacy Code
In Your Head

If all you know is hammers, then everything starts to look like a nail. Or, if you’re a meta programmer, everything starts to look like a hammer.

Some Ancient History

Back in 1998 or so, I picked up an out-of-date edition of Teach Yourself Perl in 21 days book at a Borders Books Outlet store. I read it avidly and copied every stitch of code I encountered in that book, learning with my fingers as well as my mind. By “day 15” I had picked up my very first paying Perl coding gig. For the first time, I felt I really “grokked” a programming language. That bonding experience helped me to steadfastly avoid PHP, and prepared me to jump into Java, which drove me to Ruby.

Today I was delving into Rails plugin architecture, and I got to thinking about how often, in Ruby projects, you include files which don’t contain class definitions. You just include them and the code in them runs. And that’s ok.

Class Warfare

In Perl, you have hashes which can be blessed into some nice, object-ish behavior. But since Perl was originally a procedural language, and OOP was a decidedly l33t innovation, I used to think expunging all traces of procedural code was a Fine Idea. Every file ought to contain “package Foo” and “bless $self, $type” somewhere. The phrase “use Foo” became synonymous, in my thinking, with “use a class called Foo.” And Java backed up this notion: every time you sneeze in Java you have to write accessors so that other people can catch your cold.

Objectivity Restored

But in Ruby, rather than running through the mental gymnastics involved in re-thinking all your code into classes from the outset, you get to decide when it’s best to bundle up a bit of code into a class. I think the absence of the mental gymnastics is a huge deal. It is easier to think about one thing, than to think about two things at once. Rather than straining to make all your code come out in classes, with Ruby you let your code become classes when it seems right to do so. If we’re wondering whether certain programming practices are in the vogue or not, we’re asking the wrong question. It’s more important to ask whether what we’re doing is a good decision for this project or not.

Reasonably Classy Programming

Granted, there are lots of good reasons to organize your code into a system of interactive objects. Testability is one. Another related reason is the logical legibility you get (at scale) from solid OOP principles like single responsibility and orthogonality. But to me it makes a tremendous difference to let the solution I’m building take the form which the problem suggests, rather than starting from a monumental presupposition and attempting to build solutions in its shadow.

All that to say, “wow, I can’t believe I’m still finding Perl artifacts in my head after all this time.” It’s taking me a long time to completely step out of the shadow of the monument and into the sunshine.