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.
The idea that a language should only provide a single programming paradigm, be it OO, Functional, Logic, etc etc etc, is both outdated and just an overall bad idea. In fact, the idea that a programming language should even just focus on a single paradigm is loosing ground as well. Just ask your favorite formerly-Java-now-Ruby fanatic and they will likely tell you how nice it is to have first-class blocks.
I would argue that Perl is not only the sysadmins Swiss Army Chainsaw, but also the programming language researchers Swiss Army Chainsaw too. Having implemented early prototypes of the Perl 6 metamodel in Perl 5, Java (w/ help from other #perl6-ers), Common LISP and Javascript (the last two are not online), I have to say that Perl 5 was by far the malleable of the group (LISP came in a close second, followed by Javascript). In fact, the current Perl 6 metamodel now in Pugs is written in Haskell, but was initially prototyped in Perl 5, which was written using Moose which itself is a Perl 5 port of the Perl 6 metamodel, bringing it back full circle. Try doing that in Java
I guess what I am trying to say is that anyone who tells you there is no such thing as "Perl OO" is both wrong (they are trying to be a purist, but if they are not a Smalltalk developer, they have no ground to stand on), and not very smart. Anyone who doggedly sticks to a single paradigm is almost certainly wasting a *huge* amount of effort reinventing or reimplementing the other paradims within that singular paradigm. Which reminds me of a great quote about LISP:
Any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. (Philip Greenspun)
Just remap the language names to programming paradigms and I think the same truth can be found.
- Stevan