Beefy Boxes and Bandwidth Generously Provided by pair Networks
There's more than one way to do things

Re: Perl Advocacy: Sometimes java is bitter...

by mattr (Curate)
on Feb 08, 2002 at 18:21 UTC ( #144180=note: print w/replies, xml ) Need Help??

in reply to Perl Advocacy: Sometimes java is bitter...

I got a warm feeling too and it wasn't from being combative. I see a good number of big projects these days which use Java for things Perl is awesome at, and the big difference is that it is "assumed" that an extremely expensive application server is required to make it run fast enough.

In one case many people had been fired from a web company which did not blink at recommending highly expensive servers, nor was any effort spent on considering on what the best course of action would be. And last year I managed a four month Weblogic project but when push came to shove, J2EE and the HP cluster (not my idea) got kicked out for JSP and a couple linux boxes. Lost a lot of time researching and getting training for application servers, spending client's nonexistent money, etc. End result, works just fine and yeah, if I new CGI::Application as well at the time I could have probably saved them 4-6 man-months of work doing it myself.

Another example is a product of someone's I'm handling. This Java/Tomcat thing does on-the-fly transformation of web content, based on XML queries. It seems a bit slow, reminds me of the great benchmark node I just read about XML. Now sure, the source code is closed. And there are good reasons to use Java I'm sure. But not *that* good! It feels like the pure perl XSLT transformation times that were being talked about. The main reason for Java seems to be for interoperation with the backend, but this product doesn't do that. Regardless of why it is in Java, the non-tech people are thinking it must be real advanced if it is Java. So again, lots of money is moving around because of a black box, underperforming technology and ICDIIPFHTP (I Could Do It In Perl For Half The Price).

Another example is a "senior programmer" who has developed a large, complex analysis of a sql based web logfile for one of the largest software companies around. It is in ASP. Huh? Whatever, I'm hoarse. But he went through hell.

Non-technical people decide on the technology. Seriously, Java can be great for lots of things I'm sure but spending tons of people's money on unneeded technology is not my idea of fun, even if you're told it's already decided and its take the job or forget it.

Most purchasing decisions I've seen for Content Management systems too, ought to have been Perl. Possibly not for your very high end stuff, although that may not be true either. But I'd say you could build something very very useful for less than what one license costs for one well-known package.

A rather big question of mine is, why on earth is there no Perl application server market? Are these things solid hype, or is it impossible to make money with it? Perhaps Apache+mod_perl is just perfect and too tough a competitor, but documentation is byzantine and it is not taken seriously as far as I can see. Everyone from management to sales, marketing, and even most developers know all about huge Java app servers but not about mod_perl. The worst is when Perl programming is called scripting like we're writing lingo cast directions or hypercard stacks or something. PHP or ASP are assumed to be superior to Perl unless the people who think so happen to be in my vicinity. Heck, it's hard for me to take it seriously and I've made money with mod_perl (spent a lot of time figuring it out though), because the main sites I've seen about it are years out of date.

Personally I have nothing against Java, but Perl feels a lot more of a vibrant community, and my personal time investment comes back magnified many times more than would be the case with Java. So I'd very much like to hear ideas about whether a serious application server might be realistic say when Perl 6 comes out, and whether there is any other information or package out there which is up to date and could fill the gap until then. Here's why Perl isn't taken seriously as far as I can see: (don't compare with unless you feel too good today):

Second link (Take23) has a news page not updated in 8 months Other links are similar. has files all between 1 and 4 years old. No more versions? Are we perfect? Well there is Axkit but I don't see that as a Perl app server the way Weblogic is for Java. Not that Weblogic is fast or anything as far as I can see..

That, and you never see mod_perl or Apache at a trade show I guess.

Nobody mentions application server type projects on Perlmonks. I wonder why?

At the risk of refuting myself, now I do see which is a book published this year. Is this a statistical oddity? (Wish I had their book by the way). Actually besides CPAN, the most new stuff I've seen is at ActiveState with their Perl DevKit. Now you can build Windows installers, ActiveX, COM and what have you all in Perl. Not to create a holy war (hey it's late at night) but if Java is having a crisis of faith we need a blueprint. If Perl is getting stronger with 3-countem-3 full time perl_gods working full time on great stuff and the economy helping out, Perlmonks could just be the place to talk about the future too.

A final thought. This idea must have gone around tons of times, but is there a good reason why we can't have a list of real good Perl books (I think it might include the above book just from looking at the sample chapters) and part of the sale would fund Perlmonks? I doubt a lot of people would have found that book buried in a page only I know existed out of the next 500 people I know close by.

My last word on this (sorry All) long letter to the Monks is that I have not been on the mailing list for mod_perl (I must not have seen anything when I was really active a year or two ago) but I just followed a link and yes there are Feb 2002 posts. I'm going to study that some and not shoot my mouth off. Though I still think all that above still goes and "nobody but us owls" know about the ML anyway.

Oh, mod_perl news by the way. I have a search engine (open source modules, original mod_perl code, some tweaked C++ and lots of research) which indexes all of Omron's servers worldwide. The mod_perl part has some intelligence where it picks which of 60 databases it uses depending on the language and theme you want. Funny, my mod_perl code has never gone down, server's been hit by all kinds of NT attacks, and a recent vulnerability announced about one part of the system (htdig, the single byte module now) I integrated is rendered moot by my paranoid code. Omron's like Siemens, they are the ones who just made a robot cat. Anyway they asked me for some custom dbs and soon the search engine will be EyeLatitude instead. (Mainly English now).

I always feel like I want to contribute code back to the community when it is "solid" but guess what, this stuff works great (up a year now I guess) without the sweats commercial app servers have made de rigeur. I know I'm just small fry compared to some projects using similar code underneath, but I feel sometimes like everybody is living in a fantasy world. Called up Everypath today to see what it cost, starts at a million bucks the guy said. I think that Perl is competitive, creative, and a definite plus. I can tell if a program is junk inside before it blows up on me. I have a great time every time I start a Perl project. And I highly respect people I have the honor of meeting through Perlmonks. Compared to this, much else of development appears lonely, rapacious, and disillusioned! We're so blessed()!

So I don't think there is any point in being combative, but I do think that the immense amount of enthusiasm inside the community is not making its way out into the mainstream and I think it might be close to time. We could be on a flipflop here ..

Update: Thank you for the responses, wow! Fixed the Freudian slip, thanks Grinder. Also turns out the Omron site is already using my system EyeLatitude. 10,000 searches a month so far.

  • Comment on Re: Perl Advocacy: Sometimes java is bitter...

Replies are listed 'Best First'.
Advocating Perl...
by lachoy (Parson) on Feb 08, 2002 at 21:22 UTC

    (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.

    M-x auto-bs-mode

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


      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.


      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.
      #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:~$

        eval "require $_" for ( qw( Disclaimer::Legal Disclaimer::Personal Disclaimer::Social ) );

        M-x auto-bs-mode

      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, 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 mentioned on CPAN is down too. And no OpenInteract articles at Ah, but now I've found 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.

        This is verging on a discussion that may be more appropriate on the OpenInteract mailing list (see Sourceforge), but...

        The main OpenInteract website is 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 :-)

        M-x auto-bs-mode

Re: Re: Perl Advocacy: Sometimes java is bitter...
by hackmare (Pilgrim) on Feb 08, 2002 at 18:41 UTC


    I wonder if there is the slightest hope for a public-domain language that is not being resold as a branded item backed by huge marketing budgets.

    The only backers I know of are oreilly and aspn. And oreilly seems to offer perl as an afterthought thesed days. One falls under the hyper-specialized group of hardcore tech publishers, and the other seems to be viewed with a degree of scepticism as "a commercial product trying to make money off something that should be free". Funny, how people don't back the only commercial champion for perl, no?

    maybe we just need to put out full-page ads in the WallStreet Journal, or in the other places that decision makers visit (News flash, nobody who decides whether to use mod_perl will be reading this article).


Re:x2 Perl Advocacy: Sometimes java is bitter...
by grinder (Bishop) on Feb 08, 2002 at 18:46 UTC
    well, for what it's worth, echo is working on a mod_perl book for O'Reilly with another guy. Should be ready RSN ;-)

    I haven't worked with mod_perl for a couple of years now. My memories of it were that the mailing list was incredibly vibrant, but no-one really had the time to do anything so mundane as to keep the web page up to date. Perhaps not the wisest strategic move, but that's the way it was. I suspect things are much the same as that these days too.

    g r i n d e r
    print@_{sort keys %_},$/if%_=split//,'= & *a?b:e\f/h^h!j+n,o@o;r$s-t%t#u';
      mod_perl is still alive and kicking and i myself use it all the time. I love mod_perl! Ask maverick sometime about the web framework that he is developing which uses mod_perl, Apache::DBI, Apache::Session, and HTML::Template. I personally think it kicks the dog doo out of Servlets/JSP, but it's disadvantage is that you have to be well versed to get it up and running (no pointy-clicky).


      (the triplet paradiddle with high-hat)

Log In?

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

How do I use this? | Other CB clients
Other Users?
Others about the Monastery: (7)
As of 2023-03-27 16:27 GMT
Find Nodes?
    Voting Booth?
    Which type of climate do you prefer to live in?

    Results (65 votes). Check out past polls.