Re^3: Enterprise Perl

[coreolyn]

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! :)

[punkish]

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.