>> Adam wrote:
>> Hmmm, one thing just to make sure we are talking about the same
>> thing....when I compare Java to Perl, I generally compare Java to
mod_perl
>> (or some other acclerated quasi-app server environment) and I am talking
>> about web applications as a subset of the Perl universe.
> I was talking about something more fundemental. I don't have any
> experience with J2EE, and wouldn't extrapolate from my experiences.
>
> I'd love to hear more specifics about how mod_perl compares to
> J2EE, the relative strengths and weaknesses of each platform, etc.
Note, this is all IMHO :)
.....
I think that when you are talking about enterpriese solutions, you are
concerned with things like speed, scalability, 24x7 support, integration
into other enterprise-level products (including security infrastrutures),
transaction management, the ability to support threading and database
pooling, session management, authentication support, error handling and
processing within a larger system, storage and deployment of business
objects, etc....
These are things that you expect from an application server.
At the moment, there is no application server for Perl (as far as I know).
The closest you get is mod_perl/apache. This combination kinda provides
application-server-like features for those companies who can afford to find
mod_perl or apache module capable developers (not so common as Perl
developers).
However, it is not an application server.
So far, mod_perl (or Velocoigen or any other perl accelerator) speeds up CGI
so much that it can be even faster than the equivalent servlets/JSP pages,
or ASP/COM but still this is only one of the criteria by which enterprise
web technology is gauged. There is still so many goodies provided by free
with a Java environment (once setup and assuming you have developers who can
cope with J2EE).
Granted, not every company needs such an advanced
infrastrucutre....sometimes you just need to parse a log file.
Clearly, Perl rocks the sys admin world. And it used to be the only solution
for budget web development (before Microsoft ASP). However, in the business
world, not the techie business world, there still seems to be a problem.
I guess what I am interested in finding out is if there are any ways that we
can break into the enterprise application market where the real money (read
as investment for R&D to benefit the greater Perl community) is located?
>> selena wrote:
>> What do you mean by "multiple implementation concerns?"
> Adam replied
> Remember the problems with applets running under Netscape, IE, etc.?
That.
>
> The current state of Java probably isn't that bad, but it's the
> nature of multiple implementations of a single standard to behave
> subtly differently, be it a JVM, C compiler, C++ compiler, etc.
I do think that Java suffers from this to some degree....but honestly, it is
a much more mature language in 2001 then it was in 1998. Of course, doesn't
the perl interpreter suffer the same problem across platforms as the JVM?
>> Selena wrote:
>> Many clients find that it is cheaper and more cash-flow conscious to
>> outsource support rather than maintain full time staff to do it,
especially
>> when technology is not their core competency.
> Adam replied:
> The technology marketplace is large enouugh that practically anything
> said about it is true. There are plenty of businesses where throwing
> money at the problem is the cheapest possible solution. And there
> are those who choose technologies based on the skillset of the
> largest pool of cheap talent. And there are those who choose a
> technology based on acquisition cost, maintenance cost, support
> cost, training cost, development cost, competitive advantage, etc.
>
> Sometimes those discussions favor Perl. Sometimes they don't.
I think you are right, though I think it is important to know that outside
of the US, it is not so easy to find Perl programmers compared to Java
programmers :) In fact it is hard in Europe and VERY hard in Asia.
But more to the point, I guess what we need to do is to look at all the
different enviroments there are (from SMEs to Fortune 500s, from software
development firms to genomics labs) and look for ways in which to advocate
Perl in each type.
We also need to look at where Perl has weaknesses within each environment
and provide suggestions to the Perl community as to how Perl should evolve
to better meet those needs.
