good chemistry is complicated,
and a little bit messy -LW
However, when you have to scale applications that will run upwards of 5000 transactions/minute and share code and applications accross a hundred departments you quickly see where Perl just isn't the best tool for the job.
Yes, "scalability" is the popular buzzword brought in to defend Java/WebSphere kinda stuff, but I don't buy it. First, I don't quickly see that Perl isn't the best tool for 5000 tpm. Application design, memory, hardware, network, CPU, etc. are all very important factors.
If that is not the case, I say, show me what it is exactly unique about J2EE that allows 5k tpm that is missing from Perl. I say, show me why such an application can't be programmed in Perl.
If it is a web-app, use Perl/mod_perl/fastcgi/persistent perl, whatever, buy 4 CPU Xeon processors or Sun Ultrasparc Surefire 6-cylinder servers, fill them up with 20 Gb ram each, put them on a fiber network, take away all other latencies, and then compare.
But then, the talk has moved to hardware, and I am not interested in that. I am interested in Perl. What is it about Perl that makes inherently unsuitable for the kinds of things for which J2EE is suitable?
For the life of me, I can't think of one thing!
Maybe it is the marketing. Maybe it is the fragmented nature of P5EE frameworks. There is CGI::App, CGI::Prototype, Catalyst, Mason, etc. God knows how many I don't know of.
However, when it comes to Ruby, everyone has only one word -- "Ruby on Rails." When talking about Python, every says "Zope." Now, perhaps us monktypes know better. But, perhaps we need to have others know better as well. Or, perhaps we need to tune our message so it can be carried on their waves... talk about things they can understand.
Perhaps saying that TMTOWTDI is counter-productive. Perhaps saying TOOWTDI (..only one..) is better.
Which is the point of my OP... perhaps, providing a single install with canonical, pristine, standardized, and sanitized version of most all the components one would use to create web-based or non-web-based applcations would be the way to go.
when small people start casting long shadows, it is time to go to bed