OO is Not Always the Answer

02/18/2003

An interesting thing happened to me the other day. I had to go back and write a small script in Perl. Now, I haven’t used Perl for a few years—ever since finding Ruby. Ruby is fully OO and doesn’t have the bizarre syntactic idiosyncrasies of Perl. Which I found really bothered me now.

But hey, I’m a professional, it’s like falling off a bike, right?

“Run over by a truck” is more like it. I went in, armed for bear, visions of clean little objects floating in my head. Now, you can can program Perl in an object-oriented manner. It takes a little bit of squinting, and it’s not very pleasant, but it’s doable. But this was proving to be very difficult—I wasn’t making good progress, and the program was becoming very messy far too quickly.

As it happened, the job at hand was a fairly linear, procedural task that was well-suited to be implemented in straight Perl. Not object Perl. After banging my head against the problem a day or so, I realized I was using the wrong tool for the job. I scrapped what I had started, and recoded the task in straight-forward linear Perl, with only a few supporting subroutines. I finished in about an hour and it worked just fine.

Proof again that the “best” solution isn’t always the best solution.