Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl Monk, Perl Meditation
 
PerlMonks  

Re: Enterprise Perl

by punkish (Priest)
on Aug 05, 2005 at 12:53 UTC ( #481232=note: print w/ replies, xml ) Need Help??


in reply to Enterprise Perl

So, the following is my summary of other monks' responses thus far as reasons for both impedance to the development of a P5EE as well as the acceptance of the otherwise pain-in-the-ass commercial frameworks such as WebSphere, BEA Weblogic, and their ilk --

  1. support from a single point of contact
  2. hubris of Perl users
  3. "we don't have one because we don't need one"
  4. scalability and performance
  5. Perl is a language, not a framework

Nothing really earth-shattering. #2 is not about Perl, the language, at all, so let's leave it at that. #3 seems closely related to #2 -- it may be true that we, the Perl community, have not needed one else we would have created one. However, a lot of us also have noticed how other "communities" have developed such frameworks and we have also acknowledged how they have benefited from this.

#4 is fairly bogus -- there are enough documented case-studies of Perl being used successfully in very high volume, high tpm, large dataset situations. Besides, if there are problematic applications from the perspective of performance and scalability, they can be solved with better design, and/or better hardware.

That leaves me with #1 and #5. Yes, single point of contact can be a huge issue. "Now, all those who have successfully and satisfactorily called in BEA/IBM/Microsoft/Adobe/Oracle/<your favorite large software developer> for support, please raise your hands... no one?... I thought so..." I know I have not ever got satisfactory support... and they usually ask for a credit card up-front. On the other hand, most of my technical questions get answered on Perlmonks, and then some, within the hour. Yes, a few anonymonks throw in their quips here and there, a few tell me why using CamelCase is morally wrong, or something like that, but overall, I would rate Perlmonks as a prime example of how stellar technical (as well as philosophical) support should be... do-ers helping other do-ers.

Now, we know that. How do we let the marketing-heads know that? Or the C-level people? (ever heard that? -- I heard a marketing-type use that term recently, and I was puzzled because I couldn't figure out for the life of me why he was talking about sea-level folks -- how would they be different from the mountain folks -- maybe he had just seen Steve Zissou -- then he told me that it was "C-level" -- CIO, CTO, CEO, etc. Unbelieveable, the crap these guys invent to keep themselves in business.) So, maybe marketing is an issue. Bombastic language, half of which means nothing (container managed persistence! WTF!)

The last, and perhaps the most important in my view, issue that Perl is a language, not a framework. Well, if we did develop a framework with it, say "Perl on Rollerblades," so that a single click install gave the developer Perl, a bunch of proven, certified (!), helper modules such as DBI and its brethren, HTML::Template or Template and its brethren, Catalyst and/or its brethren, a good, graphical debugger (actually, I believe Catalyst already includes one), loggin, messaging, and session modules and their brethren, etc., that would be great.

Which brings us back to #3 in reverse. We don't want one because we don't have one. Because, if we did want it badly, we would have had one by now.

Btw, while Ruby is indeed younger than Perl, Python is of about the same vintage. Even in the realm of opensource, non-commercial, non-officially-supported, high price software, "Zope," "Ruby on Rails," and "JBoss" get more name recognition and mileage than CPAN does, in my knowledge.

Update: Btw, I do realize that creating a framework is a darn difficult task, partly why it has not yet been done with Perl. That still has nothing to do with the points that: the world of Perl perhaps lacks well-publicized enterprise-ready frameworks; if they are there, they are not advertised well; there is nothing inherently specific to Perl, the language, that prevents creating such frameworks; and, not having such frameworks puts Perl as a language, as a community, as a way of doing things, at a distinct disadvantage to other such frameworks, especially in the "enterprise" (work|mind)space

--

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


Comment on Re: Enterprise Perl
Re^2: Enterprise Perl
by Solo (Deacon) on Aug 05, 2005 at 16:13 UTC
    ...so that a single click install gave the developer Perl, a bunch of proven, certified (!), helper modules such as DBI and its brethren, HTML::Template or Template and...

    ActiveState already offers this service/product for free, minus the helper modules you list (which are easily added if the ppm repositories for each are known by the installer). They also offer 'premium' cost-model support options. How does the proposition differ more significantly?

    (This post is not an advocation of ActiveState's products or services.)

    --Solo

    --
    You said you wanted to be around when I made a mistake; well, this could be it, sweetheart.

      (This post is not an advocation of ActiveState's products or services.)

      No but it is interesting. I just suddenly thought of charging my company to install perl. They would realy look at it differently then, and oddly enough I think they would like it better if they had to pay for it.


      ___________
      Eric Hodges
      Yes, ActiveState does offer this kind of service. And, yes, they also offer a 'premium' cost-model. However, they don't offer a framework a la "Ruby on Rails" or "Zope," or, something that is at least advertised (propogandized) as a framework.

      The framework standardizes the helper modules. If enterprises were intelligent, they would realize that paying for it has nothing to do with its quality... knowing that the tools exist to create it would be enough (as I mentioned in my OP, Morgan Stanley seems to already do this via "one Perl to rule them all.")

      Sadly the enterprises are not intelligent. So, unless we don't mind not occupying in that mindspace, we need to create something that the enterprises think they want.

      --

      when small people start casting long shadows, it is time to go to bed
Re^2: Enterprise Perl
by tilly (Archbishop) on Aug 07, 2005 at 06:35 UTC
    Actually frameworks have been created in Perl. Mason, Catalyst and OpenInteract2 are a few that come to mind off of the top of my head.

    Also I have to say that I've seen good help come in emergencies from Oracle. And I know people who've received it from other vendors. The trick, though, is that you need to have paid good money up front to get good support later. And you need to have good technical people on the line to the support who are able to convince the first couple of layers to get someone useful on the line.

Re^2: Enterprise Perl
by adrianh (Chancellor) on Aug 09, 2005 at 16:51 UTC
    #2 is not about Perl, the language, at all, so let's leave it at that. #3 seems closely related to #2 -- it may be true that we, the Perl community, have not needed one else we would have created one.

    It's not a Perl thing - it's an open source thing. People write code to scratch their particular itches. In the open source world frameworks tend to bubble up from the bottom, rather than be imposed from above.

    However, a lot of us also have noticed how other "communities" have developed such frameworks and we have also acknowledged how they have benefited from this.

    Like? I'm really not sure what kind of frameworks/communities you're talking about. In general anything with the label "enterprise" is something a company, rather than a community, has produced. It's a marketing term, not a technical term.

    If you're talking about things like Rails and Zope then Perl has many similar projects like Maypole, Bricolage, Catalyst, OpenInteract, etc.

    That leaves me with #1 and #5. Yes, single point of contact can be a huge issue. "Now, all those who have successfully and satisfactorily called in BEA/IBM/Microsoft/Adobe/Oracle/<your favorite large software developer> for support, please raise your hands... no one?... I thought so..."

    I've had some really excellent support responses from Oracle and Sun in the past ;-)

    But, as you say, the actual level of support is largely irrelevant. It's all about perception, and having somebody to blame.

    Btw, while Ruby is indeed younger than Perl, Python is of about the same vintage. Even in the realm of opensource, non-commercial, non-officially-supported, high price software, "Zope," "Ruby on Rails," and "JBoss" get more name recognition and mileage than CPAN does, in my knowledge.

    Now that's a much more interesting question. Although a more direct comparison would be why Rails and Zope gets more press than OpenInteract, Bricolage, Maypole, Catalyst, Krang, Bivio, AxKit, Mason, OpenFrame, etc.

    Some reasons of the top of my head:

    • TIMTOWTDI works against us. We have many different frameworks that work in interestingly different ways and so support is split. With Ruby almost everybody looks to Rails. With Python almost everybody looks to Zope.
    • Perl 5 works against us. Lots of people hate it. Sometimes with good reason.
    • Better marketing and presentation. Just compare rubyonrails.org with catalyst.perl.org.

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others rifling through the Monastery: (5)
As of 2014-09-23 03:01 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    How do you remember the number of days in each month?











    Results (210 votes), past polls