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.
So... LAMP.
Linux, Apache, MySQL, and Perl (or PHP, but I kind of promised myself this blog would be mostly PHP-free. :) ). As characterised by O'Reilly's excellent OnLAMP section, in fact, which is recommended reading, and a champion of the cause.
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
LAMP++. It's got legs, I reckon. More anon.
Re:++? --! (PLEASE IGNORE THIS TEXT)
sigzero on 2006-11-22T13:41:18
Considering the poor OO support Perl delivers, I'd say that mandating OOP is a step backwards, and hence I'd rather call it 'LAMP--'.Hmm, I would think that would depend on how far they push that. I guess since the word mandate was used then it is going to be pushed hard. I would say modules should give you an OO interface but how you implement that in the code should not be mandated. Do not restrict TIMTOWTDI (much). : )
While its debatable whether XA is really needed by 90+% of J2EE apps, its the one piece of tech which LAMP/Perl still seems to lack. (LAMP might best be compared to Tomcat, which is kindof J1.5EE)
As to "what is enterprise", I'll point to this perlmonks thread which kicks the can around wo/ ever really providing a "one true" answer.
