Buddy Burden

This is part 9 of an ongoing series where I explore my relationship with Perl.  You may wish to begin at the beginning.

This week we look at Getting Shit Done.

Last week I pointed out that one reason I stick with Perl is because it keeps evolving, so I never seem to get ahead of it.  But that’s not the reason I switched in the first place.  And that reason is still just as true today as it was 17 years ago: Perl is the language that Gets Shit Done.

Programming in C++ was fun, and I talked a bit about some things I missed in it.  But I also mentioned the big problem with coding in C++: you’re always writing libraries.  C++ is a very high-level low-level language.  That is, it makes it easy to code just about any data structure or algorithm you can think of.  Which is pretty awesome.  If you want spend your life coding data structures and algorithms.

Whereas, in Perl, it’s also easy to write all those things ... except that you never have to.  ‘Cause, in Perl, they’re already written.

Well, okay, maybe not always.  But usually.  In the past nearly two decades, I believe I can count the number of times I’ve needed something in Perl but come up empty on CPAN on the fingers of two hands, and I might get by with only one.  Sure, there are plenty of things we don’t have Perl modules for.  I just haven’t needed very many of them.  Generally speaking, when I want something done in Perl, I find that the fiddly bits and the boring bits and the fundamental underlying bits have been done for me, and I can just concentrate on doing the bits that I cared about in the first place.

And I think I mentioned that I write programs for myself a lot.  I’m one of those people who wants to write code to solve every problem that comes along.  If I could figure out how to make a Perl script make my bed, or clean my room, then those things would certainly get done a hell of lot more often.  I’d put it in a cronjob.

I’ve written code to calculate my kids’ allowances, email daily chores to them, track my hours for clients, keep track of info when hiring employees, reset the database for my music player, search for things in my instant messaging logs, organize my music collection, figure out how much space I have left in my Dropbox, balance my checkbook, query package management systems regardless of which flavor of Linux I happen to be running at the moment, calculate Weight Watchers points, track my todo list, count lines of code, print out certain lines from a file, and make a Gimp plugin to help me make cards for my favorite wargame ... and that’s just a small fraction.  Oh, and let’s not forget building D&D character sheets: a D&D character sheet was the second program I ever wrote, right after

10 PRINT "BUDDY"
20 GOTO 10

Trying to build character sheets is why I taught myself Assembly, Javascript, and the dustier corners of Excel’s formula pseudo-language.  In fact, I would say that I’ve tried to build character sheets in nearly a dozen different languages;¹ whenever I learn a new language, sooner or later I end up trying to build a character sheet in it.

Here’s a true story:  When my first child was born, we chose a first name.  We decided he’d have both my and his mother’s last names, but we hadn’t settled on the order.  We decided that one of them would be the actual surname and the other would be a middle name, instead of hyphenating them into a single surname.  But we still wanted to give him a “real” middle name as well.  So we picked ten or so candidates, and then we had to narrow that down to one, and figure out the proper name order of everything.  It made quite a few possible permutations.

So I wrote a Perl script.

It was a simple script, really.  It contained an array of the possible middle names, and then it combined that with the first name and the two last names in every possible reasonable combination, then spit them out onto the screen and let you scroll through them, and you could eliminate ones you didn’t like.  And I gave the script to his mom, and she ran through it a couple of times, and that’s how we chose the name of our firstborn son.

So, yeah, I write a lot of code, even outside work.  If there’s any obvious way to use code to solve a problem (and sometimes even if the way is non-obvious), I’m going to write a program.  I can’t fix a car, I suck carpentry and plumbing, I’m not very good at yardwork or gardening, and I’m not even particularly useful at administering my family’s eclectic collection of personal computers, laptops, and tablets, but I can write the hell of out of some code.  And I’m the type of person who will gleefully spend days trying to solve a problem with code that I could have probably just done manually in a few hours, because I don’t mind spending days on a program, ’cause it’s fun.  But just because I don’t mind it doesn’t mean I want to do it all the time.  What I’d really prefer is to get in, write the code, and get out.  Just Get Shit Done.  And that’s what Perl lets me do.

This is what Larry calls “whipuptitude.”²  He ascribes this characteristic to shell programming, and indeed I’ve written before about how I still sometimes reach for bash to solve certain problems quickly.  Sometimes it just makes more sense to me to write wc -l | awk '{print $1}' than wc -l | perl -lane 'print $F[0]'.³  Of course, once your shell script reaches pretty much any level of complexity, you abandon it and reach for Perl.  Larry has a name for this as well: “manipulexity,” which he describes as “the manipulation of complex things.” A language like C (or C++) is good at manipulexity, but crappy at whipuptitude.  But Perl can do both.  Of course, it’s the whipuptitude that I admire the most in Perl, which is what this week’s installment is all about.

Although ... writing all this out has sort of forced me to examine the other axis that Larry talks about.  I don’t think even I fully realized my feelings on manipulexity, or even complexity in general, until just now.  While pondering it, I’ve come up with a theory.  It’s admittedly only half-baked at this point, so I may want to modify it (or even reject it entirely) later, and possibly it only applies to me and no one else in the universe, but here it is anyway:

Complexity you care about is interesting.  Complexity you don’t care about is boring.

Quick example: at work, we have all these devops/sysadmin tasks that we Perl engineers have to pitch in and help with.  When we’re talking about automating our push process, for example, I find that very interesting.  Whereas when we’re talking about making our Puppet configs work, I’m bored to tears.  So, according to my new theory, it’s because I care about the one but not the other.  And that’s because one has a direct impact on me, whereas the other one has only indirect impacts.  That is, the more our push process is automated, the fewer things I have to type when it’s my turn to do the push.  On the other hand, how well Puppet works or doesn’t work only impacts me if it fails in the middle of a push or deploying a new machine.  The Puppet configs live mostly underneath my radar.  So it doesn’t impact me, so I don’t care about it, so it’s boring.

Or, perhaps a better example: I often work with data in Google Docs spreadsheets.  Retrieving, munging, presenting, and storing that data can be complex, and I find it interesting.  Dealing with Google Spreadsheets API is certainly complex too, but it’s boring, boring, boring.  In this case, it certainly impacts me, since whatever code I write has to go through their API.  But their crazy web API has nothing to do with my data, and that’s what I care about.  So thank heaven there is Nobuo Danjou and Net::Google::Spreadsheets, whose interface is sometimes still a bit lower-level than I’d like, but nowhere near as annoying as Google’s.  Danjou dealt with the complexity I didn’t care about and now I don’t have to.  Maybe he cared about that particular complexity and so it was interesting to him.  Maybe he just was forced to plow through it to get what he wanted done and decided to share in order to save others the hassle.  Either way, now I don’t have to deal with the boring bits.  Thank you, Danjou.⁴

Now, strictly speaking, this has little to do with Perl the language.  I’m talking about CPAN, about a place where programmers share libraries, and Perl certainly isn’t the only language to have that.  In fact, these days all the cool kids on the computer language block have such a thing.  Nowadays, when someone says that CPAN is Perl’s killer app, someone else will point out that several other languages have surpassed us, by various measurements.  And then of course others will come along and make arguments for why those measurements are bogus and how the other guys have way more useless modules than CPAN, or are harder to use than CPAN, or lack the awesome automated testing infrastructure that’s available to CPAN, or whatever.  I personally can’t speak to whether PyPI or RubyGems or npm or whoever might be better than CPAN.  But, even if they were, those languages don’t make it as easy to Get Shit Done as Perl does.  So it isn’t only the language, and it isn’t only the library repository: it’s the complete package.

When I ran my own company,⁵ evaluating prospective employees was always one of the most challenging parts of the job.  You have to evaluate their skills, which you can’t do from a résumé, and also their productivity and cultural fit, which is even harder from just a C.V.  One of the things we settled on pretty early was to ask for a code sample.  Then, as part of their interview process, we’d do a code review.  This not only gave us a concrete example of what they could do, but it also gave us a chance to evaluate the candidate’s ability to deal with feedback and constructive criticism (and, as a side benefit, it made it fairly easy to catch any cheaters who were trying to pawn off someone else’s code as their own).  You’d be surprised how many times I had this conversation:

“Okay, the next thing we’re going to need from you is a code sample.  Just some moderately short, self-contained piece of code that shows us that you know what you’re doing.”

“I can’t do that.  All the code I write is protected by security clearance⁶ and I’m not allowed to share any of it.”

“No, you don’t need to send us any work code.  Just some code that you’ve written for yourself.  As a personal project.”

“I don’t write code for myself.  I’m a skilled, highly-trained programmer.  When I write code, I get paid for it.”

Such peple we thanked politely and then moved on to the next candidate.  And not really because we lacked a way to evaluate their skillset.  No, it was more because if you weren’t passionate about coding—if coding was just a job to you—then I didn’t want you on my team anyway, no matter how skilled you might be.  I was looking for people who coded for fun, because they enjoyed it.  Because they just wanted to Get Shit Done.

Which is how I am.  I write at least a little bit of code almost every day.  I write in on the weekends, on the holidays, and even when I’m on vacation.  Every once in a while a day goes by where I don’t—perhaps I’m having a particularly lazy vacation day, or maybe I’m just too sick to pick up my laptop—but those are rare, and plus they stress me out.  When I spend any length of time not coding, I start to feel like I’m not accomplishing anything.  Programming is my measure of productivity.  Not saying it’s good, or right, or even healthy, but it’s how I am.  I need to Get Shit Done, and I need to code to do that.  So I reach for Perl.  Because, out of all the other languages I’ve ever learned or studied or had a casual exposure to, none of them match Perl for expressivity and productivity.  Perl Gets Shit Done.  In many cases, there’s nothing more to it than that.

Next week, we’ll explore one of the big reasons why Perl Gets Shit Done.