You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Gerd Knops <ge...@bitart.com> on 2000/06/12 01:39:13 UTC
Re: Perl vs Java [Now OT]
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).
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.
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.
Gerd
Re: Perl vs Java [Now OT]
Posted by sh...@isupportlive.com.
WAY OT at this point :)
> [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).
This is true, I haven't looked at 1.3's event handling, but honestly
what would you prefer? A single event loop? Come on.., the 1.1+
event strategy was 100x better than 1.0.2. 1.0's event handling was
crap, and that's what most event loops are designed like. This was
one area where I felt java technology was really far ahead.
(ActionListeners are key)
> 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.
Hmm., well..., here's my gripe with this. Server side perl is a
really fast developement tool. GUI side java is a really fast
developement tool. Why would you take a language that was clearly
designed for GUI developement, that all it's strengths lie with GUI,
and try to make it a server language?..., it's preposterous. It
doesn't even have REGEX's natively..., what the hell is that!?!?!
(Note: there is a really good regex library that's mostly free for
java, not nearly as fast as perl native)
> 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.
Hehe, the funny thing is that Java is actually a huge language. I
mean HUGE. But 95% of it is GUI. So if the language designers are
put 95% into the GUI... well, that speaks volumes to me. String
handling sucks, and GUI handling is good. If String handling isn't
good..., was it designed for pushing strings to webbrowsers?
Java is pretty easy to maintain, but proper perl modules are also easy
to maintain. But what I see in the field is people not spending a lot
of time to make good modules. Instead they're pushing projects out
fast, which is easy to do. Perl doesn't put any restrictions on the
developer, they are free to do things however they like. So you can
have beautiful class/module hierarchies in Perl, and you can have a
bunch of flat files that are impossible to make any mods to. In Java
everything MUST be a class. So it forces you to design things
right. But the underlying problem is what's right for one thing isn't
right for others. So Perl becomes sort of a "tool for any job", Java
becomes a tool only for a long term project. (Overhead to start)
Shane.
>
> Gerd
>
>
Re: Perl vs Java [Now OT]
Posted by Perrin Harkins <pe...@primenet.com>.
On Mon, 12 Jun 2000, Gunther Birznieks wrote:
> >Unless you use a cluster of servers for load balancing and high
> >availability, in which case you're right back where you started and you
> >need the Java equivalent of Apache::Session::DBI. I imagine someone has
> >written one in one of the many servlet runners out there.
>
> 1) Many load balancers actually recognize this and do provide some load
> balancing on IP address. This is definately not perfect of course (when you
> have ISP proxies like AOL)... and then when a machine goes down, it's just
> tough luck that the user has to get redirected and relogin or do whatever
> for the session.
It's that second part that is a problem for me. We do a write-through
cache to deal with this, i.e. we write all data to both a local cache
(shared memory, courtesy of BerkeleyDB 3) and a shared database. Reads
check the cache first, and don't bother to go to the database unless what
they want isn't cached. If a machine fails, we only lose the cache.
I know some of the commercial java stuff does the same thing and provides
a nice API for using it.
Threading certainly does have its allure, and I agree that Apache::Session
is neat and that Perl's TIE mechanism is inadequate for the job.
- Perrin
Re: Perl vs Java [Now OT]
Posted by Gunther Birznieks <gu...@extropia.com>.
At 06:01 PM 6/11/00 -0700, Perrin Harkins wrote:
>On Sun, 11 Jun 2000, Gunther Birznieks wrote:
> > 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.
>
>Unless you use a cluster of servers for load balancing and high
>availability, in which case you're right back where you started and you
>need the Java equivalent of Apache::Session::DBI. I imagine someone has
>written one in one of the many servlet runners out there.
>
>- Perrin
1) Many load balancers actually recognize this and do provide some load
balancing on IP address. This is definately not perfect of course (when you
have ISP proxies like AOL)... and then when a machine goes down, it's just
tough luck that the user has to get redirected and relogin or do whatever
for the session.
2) On the flip side of that, Java has commercial products that handle this
type of shared persistence -- one that comes to mind is Gemstone. Even so,
there are a lot of things about Java that make creating a session
persistence engine "easier".
For example, you could easily have a middleware java session persistence
engine which is actually keeping all of the stuff in RAM, but then running
a low-level thread to write stuff out to a database as it changes. Plus
keeping a socket open to each servlet engine that it wants to let know a
change in the real session made.
It's very very difficult to do the same type of architectures in Perl that
you can do with Java precisely because Perl is not a multi-threaded
language and never will be as robust in that area -- even if Perl becomes
robust in this area, the modules will have to be written to support this as
well.
Anyway, all languages have their advantages and disadvantages, but in cases
such as session handling, Java Servlets wins out big time.
Apache::Session is awesome for Perl, But take a look at all the hoops that
Jeffrey has to go through to maintain it and the code inside. It's a tough
piece of code because it is a matter of sharing a persistent session data
amongst a whole bunch of processes that don't know anything about anyone else.
And even then.
Programmers of Apache::Session still have to remember to do stuff like
manually set a timestamp or flush out the session data to disk if a
reference to a reference in a swizzled data structure is changed becuase
there is no way for the TIE interface to recognize it. These complexities
are simply non-issues in Java Servlets because of the in-memory aspect.
Anyway, I am not saying it is bad, Apache::Session is great! But it's
definately hampered by Perl's architecture.
Later,
Gunther
__________________________________________________
Gunther Birznieks (gunther.birznieks@extropia.com)
Extropia - The Web Technology Company
http://www.extropia.com/
Re: Perl vs Java [Now OT]
Posted by Gunther Birznieks <gu...@extropia.com>.
They pretty much all support Perl. Very few if any would ever support
mod_perl at US$10/month.
There is a list of ISPs in the guide (or on the web site?) that support
mod_perl, but you have to expect to pay more than US$10/month for those
services.
At 12:53 PM 6/12/00 +1000, Peter Skipworth wrote:
>Sorry to butt in - I'm sure this question is answered elsewhere, but is
>there a list of "$10 a month ISPs" supporting perl and/or mod_perl code
>somewhere on the web ?
>
>Thanks,
>
>P
>
>
> > 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...
>.-----------------------------------------------------.
>| Peter Skipworth Ph: 03 9897 1121 |
>| Senior Programmer Mob: 0417 013 292 |
>| realestate.com.au skip@realestate.com.au |
>`-----------------------------------------------------'
__________________________________________________
Gunther Birznieks (gunther.birznieks@extropia.com)
Extropia - The Web Technology Company
http://www.extropia.com/
Re: Perl vs Java [Now OT]
Posted by Peter Skipworth <sk...@realestate.com.au>.
Sorry to butt in - I'm sure this question is answered elsewhere, but is
there a list of "$10 a month ISPs" supporting perl and/or mod_perl code
somewhere on the web ?
Thanks,
P
> 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...
.-----------------------------------------------------.
| Peter Skipworth Ph: 03 9897 1121 |
| Senior Programmer Mob: 0417 013 292 |
| realestate.com.au skip@realestate.com.au |
`-----------------------------------------------------'
Re: Perl vs Java [Now OT]
Posted by dreamwvr <dr...@dreamwvr.com>.
hi,
this has been great! although my thoughts were that DB_File is way
faster than anything there is in java as a state engine.. but then again i
could be wrong.. been there done that!
Best Regards,
dreamwvr@dreamwvr.com
> Unless you use a cluster of servers for load balancing and high
> availability, in which case you're right back where you started and you
> need the Java equivalent of Apache::Session::DBI. I imagine someone has
> written one in one of the many servlet runners out there.
>
> - Perrin
Re: Perl vs Java [Now OT]
Posted by Perrin Harkins <pe...@primenet.com>.
On Sun, 11 Jun 2000, Gunther Birznieks wrote:
> 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.
Unless you use a cluster of servers for load balancing and high
availability, in which case you're right back where you started and you
need the Java equivalent of Apache::Session::DBI. I imagine someone has
written one in one of the many servlet runners out there.
- Perrin
Re: Perl vs Java [Now OT]
Posted by Gunther Birznieks <gu...@extropia.com>.
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