Advocating Perl...

(Preface: all MO, 2c, #include disclaimer, etc.)

You bring up a number of good points here. Many of them stem from the fact that Java has oodles more money behind it -- from Sun, IBM, HP, BEA, and lots of smaller folks -- and always has. It was never in the position where it was used by a number of hardcore coders and then came into the limelight as a result of its strengths. Java was going to save the world from Microsoft, remember? How's that baggage for a new language?

For the first time in a while, there are a actually number of solid Perl application server projects out there -- Mason, OpenFrame, Bricolage, Slash, but of course the one I'd point out is OpenInteract :-) The fact that you don't know about them speaks volumes -- it's really hard to let people know what's out there, to differentiate between what's usable right now and what's still in deep alpha. O'Reilly kinda functions as a central authority for Perl stuff, but they don't have the $$ to drown people in literature and knickknacks, nor the resources to go out and really beat the bushes for success stories.

One of the problems we have regarding advocacy is that we don't think like marketing people. They know they have to repeat a story a hundred times before it sticks. When someone disses Perl, we can bring up a number of high-profile, high-demand sites and projects: IMDB, Salon, British Telecom, or any of the other success stories on the O'Reilly site. But many geeks don't have the tenacity or the brashness frequently (but not solely) borne of ignorance that many marketing folks have.

Another thing marketing people do is focus on actual solutions rather than potential solutions, on products rather than infrastructure. (I know I'm terribly guilty of this with OpenInteract.) Put another way: how much legitimacy do you think PHP gained when Sourceforge became popular?

mod_perl, for all its strengths, is not an application server. It's a solid base for one but it doesn't provide the toolkit people have in mind when they think about an application server. So every time someone says, "Where are the application servers for Perl?" and we respond with "mod_perl," we sell ourselves short. Someone doing a little investigation will think we don't know what we're talking about and just move on, missing a whole body of great work.

So where does this leave us? I still think that denigrating another language is one of the best ways I know to alienate people. I think if we wanted to help the cause, we'd make it easy for people to build applications (even simple ones) very quickly and provide the tools to build complicated ones along the way. We'd build a new SourceForge in Perl and show how much better it is than the PHP version. We'd write up our own success stories and send them to ORA, or talk to our local users groups about some of the cool projects we've done or found. Because the difference between advocating Perl and Java is that we have to do the work rather than the big corporations, and our currency is time and passion rather than money.

Chris
M-x auto-bs-mode

Comment on Advocating Perl...

Replies are listed 'Best First'.
Re: Advocating Perl... by Arguile (Hermit) on Feb 09, 2002 at 16:54 UTC
"mod_perl, for all its strengths, is not an application server. It's a solid base for one but it doesn't provide the toolkit people have in mind when they think about an application server. So every time someone says, "Where are the application servers for Perl?" and we respond with "mod_perl," we sell ourselves short. Someone doing a little investigation will think we don't know what we're talking about and just move on, missing a whole body of great work." This arguement came up on mod_perl a while ago. It was generally agreed that choice is good, but sometimes the amount of choice can be overwhelming. J2EE hit on something when they had a common mail API, a common database interface, a common foo. By limiting choice and standardising a large number of components they took away a lot of the initial research as well as aiding portability. Limitation in this way isn't really the 'Perl way' but it became obvious a consolidated front needed to be presented. And this could be done by presenting reasonable 'defaults' that worked well together while not tying a developer into any "One True Way". To this end P5EE was born. (And as a sign of how hard things might be to come, the name was even hotly debated over many tens of posts ;) Quoted from P5EE (stated much better than above): Definitions The Perl 5 Enterprise Environment is the set of Perl Modules which can be used to build Enterprise Systems and the set of P5EE guidelines to be followed. Philosophy Perl Modules on CPAN are flexible, supporting many different system designs. CPAN supports many redundant modules. In fact, the slogan in Perl is "there's more than one way to do it" (TMTOWTDI). Developing an Enterprise System is different. It requires many consistent design choices. It requires the successful integration of numerous perl modules. The slogan in P5EE should be "this is one great way to do it". The fact is that there are many great ways to do it. As a result, the P5EE project supports both the P5EE:: and P5EEx:: (P5EE experimental) module namespaces. Multiple prototypical and experimental versions of "one great way to do Enterprise development in Perl" are expressed through the P5EEx namespace. The goal, however, is to reach a single expression of "one great way to do it". The P5EE namespace represents the consensus of the best great way.	[reply]
Re: Advocating Perl... by Juerd (Abbot) on Feb 08, 2002 at 21:33 UTC
`#include disclaimer` `do 'disclaimer'` `use Disclaimer` `require Disclaimer` `use base 'Disclaimer'` `2;0 juerd@ouranos:~$ perl -e'undef christmas' Segmentation fault 2;139 juerd@ouranos:~$` [download]	[reply] [d/l]
Re: Re: Advocating Perl... by lachoy (Parson) on Feb 08, 2002 at 21:38 UTC
`eval "require $_" for ( qw( Disclaimer::Legal Disclaimer::Personal Disclaimer::Social ) );` [download] Chris M-x auto-bs-mode	[reply] [d/l]
Re: Advocating Perl... by mattr (Curate) on Feb 10, 2002 at 19:50 UTC
Thank you (and everyone) very much for getting through my rant, and commenting. At the time this project was done, which was 2000 to 2001, I knew about Mason, bricolage, and I think OpenInteract at some time before but it looks much more grown up. Will certainly study all these. That said, well, search.cpan.org searching has been down for some days ("You don't have permission to access /search on this server") so your link doesn't work for me. Seems the OpenInteract site at cwinters.com mentioned on CPAN is down too. And no OpenInteract articles at perl.com. Ah, but now I've found openinteract.com from google, and now the sourceforge project, when I was about to give up. Hopefully O'Reilly will find OpenInteract or P5EE books to be a new source of income sometime soon. Okay, here's a question. I've got a CGI based intranet system to track billed time for a 40 person company. To that, I've added a CGI::Application Direct Mail system which was fun, and we are starting to plan a larger financial system which I've been thinking would be CGI::Application probably unless there is something better. The client has been very happy with these systems but I would like to integrate better and make it easy to sell/deploy. And it's time to move it all into mod_perl, and with sensitive data to PostgreSql too I think. How hard is it to port a CGI::Application to OpenInteract for example? Would you recommend OpenInteract for something like this, basically a corporate intranet/extranet server for a company or division under say 200 employees? Perhaps P5EE is already solid enough to implement and save time with it? I expect that mod_perl will make it work not just quickly, but Real Fast And Better Than X (tm). Would be nice to advertise that Perl makes it so. UPDATED 2/12: According to Chris Winter's posttwo days ago on the OpenInteract mailing list, OpenInteract is apparently going through a major rewrite (well he says not a total rewrite, but a refactoring which will require code changes..) which won't be done until the summer. Might still be possible to use parts of OpenInteract so I will keep looking at it. Thanks again.	[reply]
CGI::Application and OpenInteract.. by lachoy (Parson) on Feb 10, 2002 at 20:52 UTC
This is verging on a discussion that may be more appropriate on the OpenInteract mailing list (see Sourceforge), but... The main OpenInteract website is openinteract.org rather than .com. I'm not sure what the status of the .com website is -- I'll look into it. P5EE is (or will be) really an interface rather than something you can use directly. That is, if OpenInteract were a P5EE-compliant web application container, you could create an application to run there and it would also run in the libservlet or the aforementioned OpenFrame containers as well. From what I've seen, porting an existing CGI::Application project to OpenInteract would entail some work but it wouldn't require a rewrite. One feature they both have in common is a action (in OI a handler, in CGI::Application a script) that has multiple operations (in OI a task, in CGI::Application a run mode). So you might have a 'user' action that has the tasks 'search', 'show', 'edit', 'remove'. I think OI has this more centralized than CGI::App, but I'm not certain. However, if you're using CGI::Application right now and it works well for you, you should probably consider sticking with it and making your application mod_perl-friendly if necessary. OpenInteract has a number of other features -- like object/datasource mapping, authentication, security system, components, theming, etc. -- that for a small development team might require a steeper learning curve that is better spent on making the app work. (Depends on the size of the team, looming deadlines, etc.) Not to discourage you from using OI, it's just that I hate to see people throw away work that's doing what it's supposed to do :-) Chris M-x auto-bs-mode	[reply]

Definitions

Philosophy