At 06:39 PM 6/11/00 -0500, Gerd Knops wrote:
>dreamwvr wrote:
> > hi Gerd,
> > that was very much what i was looking for! hmm.. seems that perl is
> > definately one of the most mem efficient langs whereas java is not.
> > cool and definately great reading although "talk about detail!" this
> > is good! Java has become acceptable for a compiled language. now here
> > is a question i really am trying to understand. i really see java's
> > greatest virtue of write once use anywhere being less sensational
> > once perl becomes fully compiled lang. Well it will take some reading
> > but definately is fascinating reading. Thanks!
> >
>[OT]
>My personal take:
>Where (at least for me) Java has it's niche is client side, for
>applets and applications. But for this, 'write once use anywhere' just
>isn't true. Look at Java1.3 (which you really want to use for
>GUI-intensive stuff, though their event/keyboard handling is really not
>well thought out): Available on Windows. Period. In a year it *might*
>be out for Linux, and in maybe 1.5 years for FreeBSD (native). Mac?
>Probably not (other than OSX).
Yeah. Although applets can be useful for doing certain tricks such as
providing real time pricing feeds to a web based trading engine using
persistent HTTP streams.
>Server side it looks better, you don't need the GUI and so Java 1.1x
>is fine, and fairly available. But you can still write most things way
>faster in perl than in Java. And in my experience 'time to market' is
>way more importatnt than a program that 'looks cleaner' or maybe runs
>faster with less memory consumption. And it seems that speed/memory
>wise Java doesn't do any better than perl.
I would disagree about speed/memory wise that Java does not do any better
than Perl. I think algorithmically this is true, but there are some
practicalities that would be REALLY interesting to benchmark.
Here are a couple of things I would EXPECT would be much faster in Java
than Perl if you benchmarked a program that made use of the following features:
1. Session management. Because servlets are multi-threaded they have easy,
quick access to a shared memory pool. All the locking and shared
persistence code used in Apache::Session is rendered moot by the shared
memory Java model.
2. Would you write a chat engine in Perl? I wouldn't! (Well, actually I did
5 years ago but I am certainly not proud of that code).
The thing about a real-time chat engine is the same issue as #1, it is
really inefficient resource-wise to flush messages to a persistent data
store or even using IPC shared memory in Perl in order to allow all the
Perl processes to share a common list of chat messages even if only for the
last 5 minutes worth of chat.
Furthermore, if your chat engine supports an applet trick to keep an HTTP
stream open consistently pulling messages out of the stream, then launching
a separate Perl interpreter for each HTTP stream carries a lot of overhead
that simply having another thread off to the side does not have.
BTW, I would recommend the highest versions of JDK (stable) for server side
java, as the higher JDKs do tend to be faster and tend to have more recent
versions of libraries built for them (eg XML coding).
>One advantage Java might have over Perl is that in a team environment
>Java is easier to maintain. It is not that easy to goof up in Java as
>badd as you can in perl, and there is just 'less language' to confuse
>your fellow developer with. But again this comes with a development
>speed penalty.
I would agree with this. It does take longer to develop stuff in Java.
The other thing is portability. In Perl, I can test everything I do on a
$10 a month ISP and yet scale it to a mod_perl server later. Can't do that
with Java servlets. Try finding a $10 a month ISP that supports servlets...
Perl has a greater open source community because economic and technical
boundaries do not exist for Perl that do exist for Java when writing web
applications.
Later,
Gunther
