Re: Enterprise Perlby punkish (Priest)
|on Aug 05, 2005 at 12:53 UTC||Need Help??|
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 --
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