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.

Scaling to the demands of my work enviornment is far more than code performance. It's providing consitent interfaces, supporting ( consistent ) documentation, and a stable code base in spite of a high turn over of developers. ( Let's not forget buzzwords for sales and managers to throw around *sigh* ) While Perl can do all these things I have found very few Perl programmers that aren't out just to make something work. Their variable usage is generally that which only they can interpolate, and documentation a waste of time. Perl could be enterprise class but - oh I hate to say it - the hubris of the Perl users I have had to work with is the very thing that keeps it from general acceptance and distribution.

( I'm not even going to touch the lack of simple things like use strict and warnings outside the monestary.)

But after several years thinking on this subject I wouldn't want to change Perl folk at all. (Which is what it would take to get perl in the enterprise - moreso than any changes to its codebase or delivery platform.) I think that the culture, more than the code, is the real appeal.

update: Forgot support issues

When push comes to shove in this enviornment the status of several hundred banks and who knows how many thousands of ATM's count on our production floor. A senior executive having to count on perlmonks.org or some obscure Perl consulting firm compared to knowing they can calling on someone like IBM or Oracle is an impossible perception to overcome. Even if IBM support is horrendous the fact is our exec can tell a concerned bank president - We've got IBM working on it. Let's face it saying, "Well we've put a post on Perlmonks" just isn't going to hack it in that situation.

Damn.. got me out of my dark lurkers corner.. must get back the lights to bright! :)
coreolyn

Perl could be enterprise class but - oh I hate to say it - the hubris of the Perl users I have had to work with is the very thing that keeps it from general acceptance and distribution.

So, it seems at least one esteemed monk agrees with me partially... there is nothing specific to Perl, the language, that makes it unsuitable for enterprise deployment. It could be the Perl programmers, at least in the personal experience of coreolyn.

Unfortunately, I don't know any other Perl programmers personally, so that hypothesis is untestable by me. And, although I have been subjected to at least one instance of humiliating email-list diatribe by a well-known, and well-acknowledged abrasive Perl-er, I don't yet believe that is the reason why Perl is not in the same mindspace as J2EE.

Maybe Perl is not fully buzzword compliant, or buzzword marketed. What if the perl.org website described Perl as --

Business tools from Perl can help you track, manage, and understand your organization.

The Perl product line provides the industry's leading suite of enterprise software - helping you track performance, understand business drivers, and manage your business.

Enterprise Perl Pods (EPP) help your organization align with strategy by tracking and analyzing key business metrics and goals via management dashboards, scorecards, and alerting.

Using P5EE 2 version 8 rev 7 components, customers can create applications, browse services, view component details, and build portlets. P5EE uses container-managed persistence (CMP), container-managed relationships (CMR), stateless session Pods, a stateful session POD, PSP (Perl Server Pages) pages, and servlets.

It currently says --

Perl Facts

• Perl is a stable, cross platform programming language.
• It is used for mission critical projects in the public and private sectors.
• Perl is Open Source software, licensed under its Artistic License, or the GNU General Public License (GPL).
• Perl was created by Larry Wall.
• Perl 1.0 was released to usenet's alt.comp.sources in 1987
• PC Magazine named Perl a finalist for its 1998 Technical Excellence Award in the Development Tool category.
• Perl is listed in the Oxford English Dictionary.

--

when small people start casting long shadows, it is time to go to bed

I vaguely remember a time when CGI.pm was thought to be "the way". Not sure if the word 'only' should be in the middle of that quote, but that's a pointless digression. Python and Ruby are quite new compared to Perl. In 5 years, I would bet that they too will have MTOWTDI.

-Scott

I wouldn't say that Python is "quite" new compared to Perl. Larry released Perl on Usenet in December 1987, Guido released Python on Usenet in February 1991, just over three years later. Just over three years ago, Perl 5.8.0 was released, so you could say that Python is now where Perl was when 5.8.0 was released. MTOWTDI hasn't developped in Perl since 5.8.0. In fact, Perl has hardly changed since 5.8.0. And in five years, Python will be where Perl will be in 2 years. So, yes, Python is newer than Perl, but not so much that you can say than Perl has matured, and Python hasn't.

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.

Well, after such an investment in hardware, the $10000 you quote for Websphere isn't so bad.

I've worked with Websphere, and, it being expensive software, it sucked. It sucked a lot. But buying a licence was a lot cheaper than developing something from Perl and CPAN. (CPAN standardized? Come again? If you throw out the crap modules, the joke modules, and the proof-of-concept modules, you're left with a bunch of decent modules, most of which were either not written with each other in mind, or are not thread-safe, don't deal with Unicode well, or make assumptions on the underlaying filesystem. Mind you, there are a lot of goodies on CPAN - but almost all modules on CPAN were written to do a specific task, and weren't written to be part of a large framework).

What is it about Perl that makes inherently unsuitable for the kinds of things for which J2EE is suitable?

Nothing, but you are comparing apples and oranges. Perl is a language. Websphere is an application providing a framework. And quite a different framework than a language plus a collection of modules random programmers uploaded on an archive site the past decade.

But it's easy to proof Perl is suitable to do what Websphere and J2EE are providing: just write it, and upload it on CPAN.