Writing the previous post raised a number of thoughts while traversing the London Underground, which will keep me going in blog entries for a while, I think.
Linux, Apache, MySQL, and Perl (or PHP, but I kind of promised myself this blog would be mostly PHP-free.
Is this Enterprise Perl?
Interesting question. I think the answer is, sort of: it's its skeleton. It's the bones on which you can build an enterprise-level application in Perl. (Which reminds me - we still need to define exactly what we mean by that troublesome term 'enterprise', don't we?) But it doesn't actually define anything. A single CGI that uses the HTML generation methods and talks raw DBI to MySQL is as much LAMP as a fully OO MVC-style web application written in TT2 and DBIx::Class.
It clearly can work, though: Yahoo's internal CMS is written in Perl, so's IMDB, Amazon's publishing system, the entirety of CricInfo (trust me, I designed it - it's a TT2 fronted MVC web app, or at least it was when I left)... all these can be pointed at as examples of LAMP-done-well, and cover four of the biggest sites on the web (even CricInfo - a quarter of a billion page views a month on a single sport site). OK, so the 'L' occasionally stands for FreeBSD, but we'll draw a view over that - the spirit of the 'L' is 'Unix or Unix-alike on x86 commodity hardware', and we can let Yahoo off, just as we can excuse the folks who use Postgres. But there's really more to these than LAMP, or at least, we hope there is.
What we're looking at, from an enterprise point of view, is something I'm going to call LAMP++. I'm sure, with a bit of work, we might be able to come up with a better acronym, but by analogy with C++, LAMP++ is actually not that far off the mark. The '++' means we're talking adding, or rather mandating, an OO approach to Perl (including an OO DBI abstraction layer), some form of templating, be it TT2, Mason or whatever, and some form of Apache-embedded Perl interpreter (mod_perl). We're looking for Perl programmers, not scripters, and we'd probably really like test-driven development, too. We're taking as our bible not the Llama and the Camel, but Perl Best Practices and Intermediate Perl, and to guide our philosophy we keep handy Perl Testing: A Developer's Notebook, and Perl Design Patterns.
LAMP++. It's got legs, I reckon. More anon.
One of the accusations often levelled at Perl is that it looks like line noise. My standard defence against this is to pull out a piece of my code, which tends to be written in a clear, OO-style borrowing heavily from Perl Best Practices, with, god forbid, comments, as a counter example, which does tend to shut people up, usually with some grudging remark about 'yeah, OK, but it doesn't all look like that'.
And sadly, that's true. It doesn't. Even some of my code doesn't - if I throw together a one or two liner to do some sysadmin task, odds are it'll make copious use of $_, m// and temporary hashes with single character names, and look like one of my cats jumped on the keyboard at an inopportune moment.
Because Perl lends itself to both styles. It is, in truth, the Swiss Army chainsaw of programming languages, capable of emulating sed, awk, grep and a host of Unix command line tools, as well as C++ and Java, a place where the Perl 3-ish language constructs and innumerable clever command line flags meet the Perl 5 OO syntactic sugar that'll evolve into Perl 6 (of which more in a later post).
Some of the problem, at least, lies in its accessibility. It doesn't take much to learn the basics, and I've seen some pretty ghastly things done in the name of Perl by folks who don't know any better. At one of my former jobs, my most common complaint about some of our new hires was that they were great Perl scripters, but very few of them knew the first thing about being Perl programmers. To quote an article I found while researching this blog, there are too many people out there still writing Perl 3, treating the language like awk-with-added-cool.
If you go a-hunting for Perl resources on the net, you'll find a disturbing number of things like guestbook and article management scripts written by well-meaning people, in a very Perl 3-ish style, some of whom may even, if you're lucky, have heard of CGI.pm, but almost certainly haven't come across CPAN. Now, admittedly, you could make the case that a lot of these are targetted at folks who have a hosting account with no support for extra Perl modules. It is, though, a sizeable part of the problem - the whole perception issue of Perl being a grubby little language for doing dirty little jobs dirt cheap in a dark alley.
I put it to you, in fact, that the very title of the Camel book, "Programming Perl", is a lie. It doesn't teach you to program. It teaches you to write better Perl scripts.
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.
After a particularly brain-numbing hour attempting to persuade a development build of our main web site's Perl back end (on Debian) to actually run on a co-located RedHat Enterprise License server, I wondered aloud, with a degree of frustration, "So what the heck does 'Enterprise' mean, anyway?"
Our sysadmin, who is prone, like all of his ilk, to disparage any and all instances of rampant abuse of buzzwords, offered that it meant, among other things, 'very very slow, uses XML unecessarily, and comes with a default configuration that's no use to man nor beast'.
Mischievously (for reasons perhaps to be explained in a later blog entry), I suggested that that could be summed up in the four letters 'J2EE'.
One of my Java-savvy colleagues (in fact, all my colleagues here are Java-savvy) opined that that wasn't exactly fair, and that 'J2EE' wasn't really anything more than shorthand for 'go read this 400 page document on The Right Way To Do Things'.
I'm in the minority here at $CurrentEmployer, since I