Buddy Burden

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

This week continues the topic of why a former C++ programmer might retain some nostalgia after moving to Perl: objects.

Last week I talked about my discovery of object-oriented programming and how it led me to become a C++ programmer.  As I described, it really was an epiphany: we would say back then that I suffered a paradigm shift, although that’s become somewhat cliché these days.¹  From this you might gather that I’m an object zealot, but I’m not.

Here’s my thinking on OOP.

Throughout your life as a programmer, you’re going to run into many classes of problems.  Some of those problems will need to be solved using objects, and if you try to solve them procedurally, you’re going to create a huge mess.  Some of those problems will need to be solved procedurally, and if you try to solve them using objects, you’re going to create just as huge a mess.  But life is not black and white,² and, while it might be convenient to divide the universe of something-or-others (in this case, programming problems) into two, neatly opposed camps, the world doesn’t work that way.  So you’re also going to run into many, many classes of problems which can be solved perfectly well using either technique.  In fact, I would contend that the vast majority of programming problems fall into the middle of this spectrum.

That’s my theory, anyway, which is borne out by my personal experience.  It’s a bit simplistic, yes—it ignores other paradigms such as functional programming or event-driven programming—but it’s workable for certain discussions, such as this one.

Because what’s interesting to me is, what do we do in the middle?  That is, if you have a procedural problem, you obviously should write a procedural solution.  Of course, there are people who want to use objects for everything: CPAN has many modules where you must constantly instantiate objects merely to call a single method on it and never use it again.³  But, in general, most people will use a procedural solution for a procedural problem.  Likewise, most people will use objects when objects are required.  Sure, there are still some hold-outs who feel that objects are “overrated” or “needlessly complex” (I worked with one such person not that long ago), but, for the most part, people will use objects when they need objects.

But what about when neither approach is superior? which, as I contend, is most of the time?  What do we do then?  Should we just flip a coin?

I say, “no.” Because the assertion that either approach will work perfectly well is in fact a deceptive one.  It’s incomplete.  The proper statement should be that either approach will work perfectly well ... right now.  Because, you see, code ages.

Joel Spolsky, of course, famously contested this assertion.  Of course, like everything Spolsky writes, that article was both brilliant and moronic.⁴  Sure, he’s right that code doesn’t decay, or rust, or rot, while sitting there on its hard drive.  But code most certainly does age, and I’ll bet that every single one of you reading this knows it.  Unlike Spolsky, I’m not going to tell you that you’re wrong and you’ve been too stupid to realize it all these years.  I’m going to tell you that you’re right, and you probably were just never able to articulate exactly why.

Code “ages” because technology advances.  Because the codebase that it’s sitting in grows and changes around it.  Because the hardware it’s sitting on gets newer and smarter, and the older code doesn’t speak its language any more.  Because there are just plain better ways to do things these days, and the older code can’t keep up.  Is it true that sometimes programmers just want to rewrite everything because it’s easier than trying to understand what all that messy old code is doing in there?  Sure.  But it’s also true that the messy old code is harder to work on, less efficient, and more likely to need maintenance than new code, and that is costing your business time, and therefore money.  Is it true that sometimes programmers want to rewrite everything because the old code just offends their sense of aesthetics?  Sure.  But it’s also true that those crappy old techniques contain bugs that no one ever noticed, and now no one knows how to fix any more.  Sorry, Mr. Spolsky: code most definitely does age ... or at least there’s an equivalent process which causes it to be less useful as time passes, and we may as well call that “aging,” because it’s a commonly understood term.

And, here’s the thing: object-oriented code just ages better.  You go back to some procedural code you wrote several years ago, and it’s going to be ugly in there.  A real horror-show.  Your OOP code, on the other hand ... well, it’s still not going to be pretty, but you can almost guarantee that there will be fewer problems overall, and what problems there are will be easier to fix.  Unless you’ve tried to graft an object-oriented solution onto a procedural problem—which is a terrible idea in the first place, and certainly isn’t going to improve with the passage of time.  But, for that class of problems where neither procedural nor object-oriented is better today, you will inevitably find that object-oriented is better tomorrow.

So, while you really should consider whether you have a real choice or not before beginning, once you do determine that you have a choice, you’re nearly always better off choosing OOP.  Good; that’s one choice down.  But it’s hardly the only choice you’ll need to make when starting a project.  In fact, much more of our programming lives are ruled by another choice: do it fast, or do it right.

Now, just like procedural vs object-oriented, this is not really a binary choice.  But there are definitely two opposing forces that act on us.  Time pressure is something we often associate with work: we imagine that only pointy-haired bosses demand that things get done faster.  But, in fact, we put time pressure on ourselves even in our personal projects: we know that we can’t move on to the next thing until we finish this one, and who wants to spend a lot of time on one problem?  Variety is the spice of life and all that.  In fact, when we are inexperienced programmers, time pressure is the biggest pressure there is.  It takes a few years under our belts—a few instances where we have to go back and actually maintain the code that we wrote quickly as immature coders—before we start to put pressure on ourselves to do things properly, not to take shortcuts, to spend some time making sure that the code will be easier to change once that becomes necessary.  And time to learn that it will become necessary ... it’s always necessary, unless you need to rewrite the code entirely, and tell me that isn’t a sign that you should’ve paid more attention to doing it right the first time.

So, for most of us, we start out spending more effort in doing it fast, until we have to maintain our own code for a while.  And then we spend more effort doing it right, until we realize we’re not ever finishing anything.  And, eventually, we find the proper balance.  But still there will be day-to-day fluctuations on the amounts of these two pressures, in different situations at different times.  And now I’ll finally come back to Perl, which is after all where we started.

I mentioned that, for a time, I was bilingual in both C++ and Perl.  This meant that, every time I sat down to write a progam for myself (which, as I mentioned, I do a lot), I would have to decide whether I wanted to write it in C++ or Perl.  There were many factors that would influence that decision, but one of the biggest was whether I wanted to use objects or not.

See, objects were easy to create in C++.  Whereas, in Perl, it was possible to create objects, certainly, but it was a bit of a pain in the ass.  Lots of boring, boilerplate code involved in hand-rolled objects.  This meant that the “do it fast” force pressured me towards Perl (where I could quickly Get Shit Done), but the “do it right” force pressured me towards C++.  This is a terrible place to be.

Of course, it actually got a bit worse once I left C++ behind.  At that point I was in the position of “do it fast” pressuring me not to use objects.  Oh, sure: if I was facing one of those problems where objects were obviously the right answer, then I’d suffer the pain of hand-rolling the objects in Perl.  But when I was in the position of either procedural or object-oriented solutions being equally good (today), I would rarely bother with the hassle of using objects, even though I knew I’d regret it (tomorrow).  The language itself was working against me, in a sense.

Which is why Moose becomes vital to my Perl experience.  Which is what we’ll look at next week.