Re: Perl vs Java

2000-06-11 Thread shane

Well, I'll just drop my $.02 into this discussion.  I've done a lot of
both.  The site from which this email is coming from
(isupportlive.com) is developed in java technology start to finish.
Everything is either a .jsp, or straight servlet.  I've also developed
a lot of other sites using modperl, and cgi's.  (Cgi's a few years
ago, but everything for the last couple years has been modperl)  Also
for the isupportlive site there are java applications, and java
applets that use the servlets as their inter-communication method.

So given that information, I'll give you the run down on how I feel
about it.  After spending 6 months developing all that stuff, I think
it would have been wise to have the entire backend done in C or perl
instead.  I've done bench marks on both, and Java is a huge memory
hog, and not too much in the way of stable.  Speed wise, a perl
solution would have been better, but really for what I was doing C is
the only way to go, or maybe threaded perl when modperl2 comes out.

There's a lot of cool stuff "built in" to servlet technology that's
not immediatly obvious in perl technology.  But with stuff like
Embperl, Apache::ASP, and Mason, it sort of levels the playing field.
The worst thing about Java though for me is that the community isn't
as "giving".  The perl community is built on a very open tradition,
and the language itself is more extendable with native plugins.  (I.e.
you can build something in C in XS, and have it run non interpretted)

So the MOST important thing about perl is, well..., basically you
guys!, the perl community.  Java doesn't have that.  Native languages
have it, but not as organized as CPAN, etc.  Java doesn't have it...
not at all.  People are not nearly as open with their class files as
people are with their .pm's.

Honestly though..., I love the java language.  But the best thing
about java has nothing to do with Servlets.  It has everything to do
with the GUI class layout.  The inheritence there is pure beauty.
Have you every tried to use String tokens in java and run a benchmark
on it and compared it to a regex?  PATHETIC.  String handling is crap
in Java.  The explanations I've heard are overhead for creating string
objects for each token seperator.

Oh well, those are my disorganized thoughts :-)
Shane.


On Sun, Jun 11, 2000 at 09:37:14AM -0600, dreamwvr wrote:
> hi,
>this could be a can of worms but anyhow here goes. Has anyone timed the
> actual efficiency of Perl vs Java? Reason being is i wrote a state engine as 
> a perl module that seemed quite fast ~ 0.33 to 0.54 of a second for slurping 
> up values. With recall being about .25 to .35 of a second which seemed quit fast
> to me. Then i was shown a jsp page which i really don't know much about..
> reminded me actually of SSI syntax wise. Well it was doing the same thing using 
> Java persistance objects and seemed very fast. Any idea how the languages
> compare as always trying to use the best tool for the job. 
>   TIA
>   [EMAIL PROTECTED]



Re: Perl vs Java [Now OT]

2000-06-11 Thread Gunther Birznieks

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 SkipworthPh: 03 9897 1121   |
>|  Senior Programmer  Mob: 0417 013 292   |
>|  realestate.com.au   [EMAIL PROTECTED] |
>`-'

__
Gunther Birznieks ([EMAIL PROTECTED])
Extropia - The Web Technology Company
http://www.extropia.com/




Re: Perl vs Java [Now OT]

2000-06-11 Thread Peter Skipworth

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 SkipworthPh: 03 9897 1121   |
|  Senior Programmer  Mob: 0417 013 292   |
|  realestate.com.au   [EMAIL PROTECTED] |
`-'




nicknacks

2000-06-11 Thread The Doctor

1)  Anyone noticting any problems with perl5.6.0 and Apache SSL?

2)  What date/time/welcome message functions are available from mod_perl?



Re: Perl vs Java [Now OT]

2000-06-11 Thread dreamwvr

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,
[EMAIL PROTECTED]
> 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]

2000-06-11 Thread Perrin Harkins

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]

2000-06-11 Thread Gunther Birznieks

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




Re: Any tips or hints?

2000-06-11 Thread Robin Berjon

At 19:23 11/06/2000 -0400, J. Horner wrote:
>Perhaps I've misread something.  I was trying to make my module,
>Apache::TimeOut, usable on CPAN.  I wrote this module to provide
>configurable timeouts for certain web pages.  I am just trying to
>find a way to put this is in the CPAN archive.  Any good links on
>making the Makefile.PL, the documentation, and the .tar.gz file
>needed to list this on CPAN?

There's a new man page being created:

http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2000-05/msg01095.html



-- robin b.
James Joyce -- an essentially private man who wished his total indifference
to public notice to be universally recognized. -- Tom Stoppard




Re: Perl vs Java [Now OT]

2000-06-11 Thread Gerd Knops

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: Any tips or hints?

2000-06-11 Thread J. Horner

Rob Tanner wrote:
> 
> I am perhaps seriously missing your point.  The stuff in chapter 8 is
> mainly about httpd.conf -- custom config directives for you module and
> using perl to configure apache.  There's nothing really there about
> .htaccess.  If you are planning to use PerlSetVar directives in .htaccess,
> there's nothing special you need to do other than read their value.  On pp
> 455-456, check the description of dir_config().  From what your describing
> below, you don't need to make custom directives, and anyway, PerSetVar and
> custom directives are two entirely different things.  You simply use them,
> you don't define them in Makefile.PL.
> 

Perhaps I've misread something.  I was trying to make my module,
Apache::TimeOut, usable on CPAN.  I wrote this module to provide
configurable timeouts for certain web pages.  I am just trying to
find a way to put this is in the CPAN archive.  Any good links on
making the Makefile.PL, the documentation, and the .tar.gz file
needed to list this on CPAN?

Thanks,
JJ


-- 
J. J. Horner
[EMAIL PROTECTED] http://www.knoxlug.org
System has been up: 4 days.



Re: Perl vs Java

2000-06-11 Thread dreamwvr

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!
 
[EMAIL PROTECTED]



Re: Perl vs Java

2000-06-11 Thread Perrin Harkins

On Sun, 11 Jun 2000, Matt Sergeant wrote:
> There are posts in the archive about this. Here's a quick summary:
> 
> You can make Java slow. You can make mod_perl slow.
> Java (servlets, jsp, etc) can use a lot of memory. mod_perl can use a lot
> of memory.
> Servlets can be very fast. mod_perl can be very fast.
> 
> I think that covers most of the arguments.

This cracked me up!  Thanks Matt.
- Perrin




Re: Perl vs Java

2000-06-11 Thread Gerd Knops

dreamwvr wrote:
> hi,
> this could be a can of worms but anyhow here goes. Has anyone timed
> the actual efficiency of Perl vs Java?
>
> [cut]
>
I found this of some interest:

Computer Languages compared
http://wwwipd.ira.uka.de/%7Eprechelt/documents/jccpp_tr.pdf

Gerd



Re: [performance/benchmark] printing techniques

2000-06-11 Thread Gisle Aas

Stas Bekman <[EMAIL PROTECTED]> writes:

> And the results are:
> 
>   single_print:  1 wallclock secs ( 1.74 usr +  0.05 sys =  1.79 CPU)
>   here_print:3 wallclock secs ( 1.79 usr +  0.07 sys =  1.86 CPU)
>   list_print:7 wallclock secs ( 6.57 usr +  0.01 sys =  6.58 CPU)
>   multi_print:  10 wallclock secs (10.72 usr +  0.03 sys = 10.75 CPU)
> 
> Numbers tell it all, I<'single_print'> is the fastest, 'here_print' is
> almost of the same speed,

'single_print' and 'here_print' compile down to exactly the same code,
so there should not be any real difference between them.

-- 
Gisle Aas



Re: Perl vs Java

2000-06-11 Thread dreamwvr

hi,
   thanks.. well i walked into that one;-)) anyways really was trying to see
which was better from a web serving point of view.. in maintaining state 
between cgi pages.. since i have not done any real java proggies since 
the first year of jdk coming out i really was surprised how fast it was since
my previous experience had been that java was very slow. yeah..yeah
the args about scripting vs compiled to go on forever but just wanted to 
see which offered the best efficiency according to tests that had been 
made using basically the same i/o . TIA



Re: Perl vs Java

2000-06-11 Thread Matt Sergeant

On Sun, 11 Jun 2000, dreamwvr wrote:

> hi,
>this could be a can of worms but anyhow here goes. Has anyone timed the
> actual efficiency of Perl vs Java? Reason being is i wrote a state engine as 
> a perl module that seemed quite fast ~ 0.33 to 0.54 of a second for slurping 
> up values. With recall being about .25 to .35 of a second which seemed quit fast
> to me. Then i was shown a jsp page which i really don't know much about..
> reminded me actually of SSI syntax wise. Well it was doing the same thing using 
> Java persistance objects and seemed very fast. Any idea how the languages
> compare as always trying to use the best tool for the job. 

There are posts in the archive about this. Here's a quick summary:

You can make Java slow. You can make mod_perl slow.
Java (servlets, jsp, etc) can use a lot of memory. mod_perl can use a lot
of memory.
Servlets can be very fast. mod_perl can be very fast.

I think that covers most of the arguments.

-- 


Fastnet Software Ltd. High Performance Web Specialists
Providing mod_perl, XML, Sybase and Oracle solutions
Email for training and consultancy availability.
http://sergeant.org http://xml.sergeant.org




Perl vs Java

2000-06-11 Thread dreamwvr

hi,
   this could be a can of worms but anyhow here goes. Has anyone timed the
actual efficiency of Perl vs Java? Reason being is i wrote a state engine as 
a perl module that seemed quite fast ~ 0.33 to 0.54 of a second for slurping 
up values. With recall being about .25 to .35 of a second which seemed quit fast
to me. Then i was shown a jsp page which i really don't know much about..
reminded me actually of SSI syntax wise. Well it was doing the same thing using 
Java persistance objects and seemed very fast. Any idea how the languages
compare as always trying to use the best tool for the job. 
TIA
[EMAIL PROTECTED]