On Sun, May 27, 2001 at 10:28:29PM -0500, Bob Tanner wrote:
> Ok, soapbox time, this is not flamebait. It will probably show my ignorance on
> how far perl has come.  Hopefully some perl mongers are here so they can set me
> right.

Guess that's me.  I'll admit my biases up front:  I've never touched Java or
even looked at it aside from a bit of sample code in magazines here and there
that used it insted of C.  I regularly curse web sites that insist on using
client-side JavaScript, but I've been told that Java and JavaScript are
completely different things.  I'm curious about PHP, but have never really
bothered to look at it.  From the descriptions I've heard, though, PHP sounds
like a markup syntax on steroids rather than a real programming language.

But I'm a big fan of perl and have done apache module programming in both C
and perl, so I should be able to respond to some of your statements...

> Servlets are faster, especially when dealing with large database queries. In
> particular, objects that deal with lookup tables. Because servlets are
> persistent, you can at start up time perform one-time initialization routines. 

Using mod_perl, you can create a startup script (using the PerlRequire or
PerlModule directive) which will run at server startup, when the mod_perl
environment is set up.  Anything it does (like setting up DB connections or
precaching data) is then inherited by all child processes.

Also, individual perl modules are persistent within each child process.
One of the things frequently stressed in the documentation I've seen
on writing perl modules for apache is that you have to clean up after
yourself, because the next request delegated to that child will have
whatever environment you leave behind.  It seems that many CGI programmers
are in the habit of assuming that the world ends when their script does,
so they don't bother closing files, etc.

> Servlets "perform" better in an international community. While most Americans
> thing the Internet is "ours". Internet is global. One of our clients is an
> international organization in over 25 countries. Java's localization APIs make
> an international web site not only possible, but relatively easy.

Perl has support for the locale system and, from a quick look at the perllocale
documentation, it appears to be pretty straightforward.  Not knowing Java's
relevant API, though, I can't compare the two meaningfully.

> Java has native thread support with priorities. So servlets can "perform" nicely
> with each other more easily. One particular application I wrote has a "long"
> (60-120 seconds) processing cycle. The information is not time sensitive. So
> putting this request into a very low priority thread helps servlets scale. I
> don't think perl can do this (perl monger flame?), so ever perl cgi is give same
> priority.

IMO, you've got the wrong model here, whether you're using perl, Java, C, or
anything else.  Processing unrelated to the display of a web page shouldn't
be running within the web server.  Create a standalone program to do the
background processing and spawn it, as a previous poster suggested, under
nice(1).

If you're really into threads, perl supports them through the Threads
module, but, as always, using them complicates your resource handling
and the 'what if this child gets another request while still processing
the last one' case becomes more complex.  IMO again, I've always thought
threads are overrated and the time I spent writing apache modules for
Win32 apache (which spawns handler threads instead of handler processes
like the *nix version) has only reinforced that opinion.

> Servlets perform better with legacy systems and non-Unix based systems (ok, perl
> mongers are going to have to flame me on this).

<flame>
Bob, you're an utterly clueless moron and have no idea about what you're
talking about - or anything else, for that matter!
</flame>

How's that?

Anyhow, I've heard that perl is currently much closer to the 'write once,
run anywhere' ideal than Java.  Granted, that's just hearsay, but, if it's
true, it would seem to indicate that perl is the stronger cross-platform
language.

> Talking to MS SQL Server is no different then talking to MySQL or Postgres. It's
> all JDBC. 

DBI, as an earlier response mentioned.

> Wanna talk XML, there is Xerces-J (yes, there is Xerces-perl too). 

XML::Parser is the most popular XML parser for perl and was originally
written by Larry Wall himself.  You can't get much more perly than that...

> Printing html from your browser not good enough? Converting the data from html
> into a pdf via FOP is no problem.

That's another one I'd use an external program for.  (Well, actually, I'd
avoid it if at all possible.  PDF is evil.)  However, perl does have the
Text::PDF family of modules.

> Need to produce a fancy report with SVG (scalable vector graphics)? Grab Batik
> and you got everything you need.

The SVG-PL site notes that "The CGI demos make real time use of SVG-PL".
Turn 'em into mod_perl demos and they'll just get faster.

> What to keep your DB object, Business Objects and Presentation (html) Object
> _TOTALLY_ separate so you can yank out the html and replace with wxml, wap or
> iDEN? Grab Enhydra and you got it made in the shade.

I'm not familiar with enhydra, but this sounds more like an architectural
issue than a language issue, although the specific tool which enables the
better architecture appears to be language-specific.

> Think working with the request/response model of web request is a step
> backwards? Grab Barracuda and change your web application into a Model2 Event
> Model machine (just like Swing).

And you've lost me once again, but I think that since the web runs on
requests and responses, that's a very natural model to use when coding for
it.

> Is keeping your production, development and deployment servers in-sync a
> nightmare? Bundle all of your Java objects, images, and config files into a WAR
> (web archive) and just distribute 1 file for easy upgrades.

Sounds pretty cool.  But can't you get basically the same effect with
tar/cpio or cvs?

Having never been into Java, I can't present much in the way of a list of
perl's points of percieved superiority, I'm afraid.  I use perl because I
like it and I like it because it's the most fun of all the useful languages
I've learned.  (I have a vague memory of Scheme being ridiculously fun to
work with in the one course I took that used it, but, at the time, it didn't
seem even marginally useful.  Now I hear people talking about being able to
accomplish things with LISP, so I suppose I should take another look at it
real soon now.)

I guess I can come up with one reason to use perl for web work:  Web servers
accept a string of text, do something to it, and send another string of text
back.  Perl seems to be an obvious choice for use in the server because
nothing else (that I've seen, anyhow) slices-n-dices text like perl.

-- 
That's not gibberish...  It's Linux. - Byers, The Lone Gunmen
Geek Code 3.12:  GCS d? s+: a C++ UL++++$ P++>+++ L+++>++++ E- W--(++) N+
o+ !K w--- O M- V? PS+ PE Y+ PGP t 5++ X+ R++ tv+ b+ DI++++ D G e* h r y+