Beefy Boxes and Bandwidth Generously Provided by pair Networks
No such thing as a small change
 
PerlMonks  

Re: Enterprise Perl

by coreolyn (Parson)
on Aug 04, 2005 at 17:22 UTC ( #480948=note: print w/ replies, xml ) Need Help??


in reply to Enterprise Perl

I feel your pain! And have felt it for the last four years or so as I'm in a Websphere shop. I refuse to defend WebSphere as I think its a mockery of J2EE. 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.

I've always stuck my nose into every enterprise Perl discussion hoping to either think or discover an angle that would make it more palatable to large corporations beyond that of a batch/scripting language. At this point I'm realizing Perl does what it does. Inspires inovation, solves crises, and gives me an edge over other developers when the heat is on. I find I'm not looking to make Perl into what it isn't, but constantly looking for where I can take advantage of it as it is.


Comment on Re: Enterprise Perl
Re^2: Enterprise Perl
by punkish (Priest) on Aug 04, 2005 at 17:38 UTC
    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

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

Re^2: Enterprise Perl
by Anonymous Monk on Aug 05, 2005 at 23:32 UTC
    I am right now in the final stages of building a large distributed peice of software in perl for enterprise use. It will be issuing an estimated 24/7 average of about 200 transactions per second to a relational database, with peaks up to double that for short periods. It will be receiving data updates from 5,000+ machines in multiple datacenters to drive these transactions. The relational database itself will be holding 1-2 TB of data, a good third of which is constantly being recycled in a matter of days. Every last little peice of code (on the 5,000+ machines, and the central server, and the midlayer between them) involved is written in perl, with the exception of some small peices of code in database trigger functions that's written in sql. So far, it's working great. In some ways, perl is no different than C - it can do whatever you want, as long as you code it correctly to do so.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://480948]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others about the Monastery: (15)
As of 2014-07-31 14:59 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite superfluous repetitious redundant duplicative phrase is:









    Results (249 votes), past polls