Thursday, 23 November 2006

"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.

1 comment:

Adam said...

So, good programmer in any language can often massively outstrip bad programmer in any language, no matter how good or bad the languages, yes? And anything that lets you quickly sort the good from the bad without having to spend 6 months watching them do a very extended interview ;) is a good thing? I think that's a fairly widely accepted line of reasoning these days.

So, Mike ... could you answer this question?

If high-level programming is good, and systems now run even interpreters fast enough for most business logic situations (the limiting factor these days is your data structures, your volume of data transferred, your iteration time for algorithms, etc), so that you are free these days to select your language from among any scripting language, systems language, or antying in between...

...then why is it a good idea to write in a language that predated the modern buzzword ones (like java and C#/CLR/.NET that dominate the enterprise industry) by some distance and lacks most of the protections and control systems and time-saving features that have come since?

(for avoidance of doubt: as far as I'm aware the vast majority of those can optionally be added to perl or used optionally in perl programs, as is the case with any fully expressive language; my question is about the reduced certainty of the usage of these because things that in perl are optional user-written libraries are often intrinsics in other languages, giving project owners much better guarantees and protection against bad coders)