"OO Perl"

A couple of people on the use Perl; version of this blog picked up on my use of 'OO Perl' as a term, and were less than complimentary about the language's OO features. I'm not here to defend that: however, it set me thinking about why I used that term, and whether it was what I actually meant.

It was, at least in part, prompted by my job search (more on that later, I promise). Look down jobs.perl.org, and you'll find that most of the well-paying jobs mention, in some roundabout way, LAMP or a variant thereof, and stipulate 'OO Perl'. The fact that I had 'OO Perl' (and legitimately so) on my CV (resumé for you transPondials) was welcomed with open arms by several recruiters who absolutely couldn't wait to get my details to their clients.

I think, in the end, this goes back to some of the comments I made about the Swiss Army Chainsaw, specifically, the distinction between Perl scripters and Perl programmers. How do you tell if someone's the latter, if their CV just says 'Perl'?

I don't think 'OO Perl' necessarily has to mean, literally, Perl in the Perl5 "bless {};" way. What the recruiters are trying to say, I'm pretty sure, is 'someone who treats Perl like a high-level programming language'. 'OO Perl' is, if you like, a shibboleth, to find the programmers amid the scripters, since a scripter's response will be either 'huh?' or 'no, that's scary'. (Joking a little, but you get the point.) It isn't, by any means, a perfect test, but it seems to me that if someone both uses OO Perl, and consciously self-identifies as doing so, they fall on the 'programmer' side of the divide.

And of course the problem, both for the recruiters and for our definition of LAMP++, is that Perl the language doesn't mandate it. Any more, actually, than Java the language does. You can quite happily write little Java ten-liners to do some mundane task that mangles a file, and never consciously touch an OO feature of the language. You can write really bad Java just as much as you can really bad Perl.

But... and here's the kicker... The frameworks that most Java enterprise projects are written in pretty much do mandate an OO approach, and what my Uni lecturers would call 'good software engineering principles'. And that means that folks raised in that environment have it as a similar shibboleth to 'OO Perl' to prove their credentials in the Java world. Now sure, once you start using Class::DBI, Rose::DB or DBIx::Class for your DBI abstraction layer, or a goodly number of the popular CPAN modules, you're at least required to talk to them in an OO way. But there's nothing to stop your actual application code being a Big Ball Of Mud, a God Object, or any number of other anti-pattern horrors.

Which reminds me. I should talk about Design Patterns.