It's clear from watching $CurrentEmployer's recruitment, that if you're in search of Java Enterprise developers, it's not only easy to find a whole boatload from which to pick, but a trained monkey can go play buzzword bingo on their CVs to reduce it down to the half dozen key acronyms that get you what you want: Java, J2EE, EJB, Tomcat, JSP, JSTL. For a bonus, add on Eclipse, Hibernate, XML and its children, UML and the like, and you can pretty much come up with a short list of candidates who you know will have the skills you need to develop in a Java Enterprise environment. And more to the point, it'll be very similar to the environment they came from and are used to. And the list won't actually be that short.
Switch to Perl, and... well. For Java read Perl. Easy enough. For J2EE read... Um. Let's skip that one. For EJB... uh, moving right along. For Tomcat, we have mod_perl + Apache: that's fair enough. For JSP? Template Toolkit, or Mason, or Embperl, or... a whole list. For Eclipse...? How many people actually use an IDE with Perl? For Hibernate, we have Class::DBI, or DBIx::Class, or several other layers of varying depths of abstraction.
And there's one of the problems: that great virtue of Perl, that There's More Than One Way To Do It, comes and bites us - not everyone who holds their hand up and claims to have developed using Perl-in-the-Enterprise has anything like the same set of core knowledges. Going back to J2EE - there's that 400 page document that defines it, and the big driving force that's behind it, Sun, centralising the definition of what is and isn't part of J2EE.
We don't have that in Perl: take a look at the rich diversity of CPAN, the archive that almost defines 'TMTOWDTI'. It's great - given a task you can pretty much bet the project that you'll be able to find a module to do it. Except... to take an entirely random example simply because it cropped up today: I wanted to populate our user DB with GUIDs. It seems likely that there should be a module in CPAN to do it, right? So let's look.
Hallelujah! There is!
Without looking at all hard, in fact, there are three. One's dependant on another, and the third seems to be completely standalone.
And nowhere is there a standard, a definition, a set of guidelines, that says "use this one, 'cause it's the best" or even "use this one because we know what we're talking about and we say so."
To be fair, there are now a bunch of modules that ship with the core Perl distribution that are the approved way to do various basic Perl tasks, and without which Perl pretty much won't do anything useful. There are also modules that have reached the status of being the de facto standard for a task: CGI and LWP::UserAgent are two obvious candidates.
But there are also cases where there are many, many modules: consider the Date:: sprawl for one, the vast array of things with Template in the name, the various DBI abstraction layers, the countless bean-like Class::* modules... And there's no finger pointing at us to say 'this one'. Sure, we can define a corporate standard that says we're going to use Date::Simple, Class::DBI and TT2, and that's fine for us. But the next guy may decide to use Date::Manip, DBIx::Class and Mason, and architect his app a completely different way. There is no standard.
Of course, the obvious question is 'does this matter?' And I'm going to leave that for a later post.
