RE: Perl vs Java (XML Modules)
>True. As for praise, XML::Parser does the job for me. In this specific >case, I'll be looking for something like failure in the >response to an XML request I send. I'd like to pull out just the section >that failed and be able to create another request from that XML chunk. >It's a little down the road, but I'm trying to plan today. If it's that simple, then try XML::Simple and use XMLin. That package makes basic XML stuff incredibly easy. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Perl vs Java (XML Modules)
Matt Sergeant wrote: > > On Tue, 5 Dec 2000, Drew Taylor wrote: > > > I know this goes a little off topic, so I apologize in advance. > > I changed the topic for you :-) But now it seems like flame bait ;-) > > One big sticking point with Perl I'm just starting to run into is XML. > > Yes, Perl has great XML modules, and many more promising ones. But where > > is the _validating_ XML parser? I'm doing some XML work where a > > validating parser would be very nice, speed hit or not. I can work > > around it easily (this is perl :-), but it would save me some work. > > XML::Checker. > Also see www.perl.com which links to Kip Hampton's XML.com article about > validating using XPath. I'll look more into XML::Checker. Apart from being alpha, it seems like it will work nicely. I guess I could help with the alpha status if I choose. :-) > > The XML & Java combination has a LOT more corporate resources (read $$$) > > focused on it than Perl & XML. How many Java-based XML software > > announcements have you seen lately? Now compare that to Perl-based XML > > modules. The numbers don't compare very well. What can we do about this? > > Very little, except produce our own XML modules that can do our work. And > you can help by praising those that do produce good XML modules and by > using the modules that work rather than those that don't (hint: XML::XPath > vs XML::DOM with XML::XQL). Apart from validation, what are you missing? True. As for praise, XML::Parser does the job for me. In this specific case, I'll be looking for something like failure in the response to an XML request I send. I'd like to pull out just the section that failed and be able to create another request from that XML chunk. It's a little down the road, but I'm trying to plan today. > > I can't help write a validating parser, but I would be happy to help > > test it out. IMHO, more XML support would help sell perl into more > > corporate settings. Java is big into buzzwords, and XML is one of the > > biggest there is at the moment. And as we know PHBs like buzzwords, so > > that is one more point in Java's favor. > > Actually XML is one area where mod_perl kicks Java's butt in some ways. > AxKit is *faster* than Cocoon. Please test and see for yourself if you > don't believe me. And building XML based web sites with AxKit is *really* > easy. I built modperl.sergeant.org in 10 days of spare time, including a > content management system for the news articles (note that half of the CMS > code is just a plain mod_perl handler). I'll stick an article online > shortly about how the site is constructed. When AxKit first came out, I was very excited about it but never had a chance to play with it. And it gives me (and you I'm sure) great pride that perl's XML app server is faster than the equivalent Java version. ;-) I hope to have a play server at home soon so that I can begin playing with cool new toys like AxKit and A0. My experience with XML is limited at the moment, but I'm learning quickly. -- Drew Taylor Software Engineer OpenAir.com - Making Business a Breeze! Open a free account today at www.openair.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: perl vs java
> Now, now...that is unfair. I was referring to writing in pure Perl vs pure > Java. > > Of course, C apis and pre-written daemon integration makes the glue > language a moot point (and favors Perl actually). Well, mine is pure perl. it can speak the protocol to integrate with a pre-written C irc daemon, but you don't *have* to use it with one. > BTW, is select() is still broken in Win32 Perl? It was 6 months ago (I > suspect because IO operates differently on win32) so you'd limit your > platform too. Last I heard, perl's select() under win32 worked for sockets, but not for pipes or ttys. Anyway, limiting myself to platforms where select() works doesn't strike me as a bad thing... -- Roger Espel Llima, [EMAIL PROTECTED] http://www.iagora.com/~espel/index.html
Re: perl vs java
On Tue, 13 Jun 2000, you wrote: > Now, now...that is unfair. I was referring to writing in pure Perl vs pure > Java. Admittedly it's not completely fair :-). I admitted that I would do (have done) it in c. Given a choice between C and perl that is. But as you say in the next paragraph, Perl is clearly a better choice than java on this. (Although if you're only supporting JDK1.1x and later, the ability to pass java objects over HTTP is really cool, and I used it extensively) > > Of course, C apis and pre-written daemon integration makes the glue > language a moot point (and favors Perl actually). > > BTW, is select() is still broken in Win32 Perl? It was 6 months ago (I > suspect because IO operates differently on win32) so you'd limit your > platform too. Honestly I don't know much about the Win32 platform. Until I had to use VMWare to look at a prototype for a product I was helping out with I hadn't used Windows in about 2 years. (BTW: Huge plug for VMWare, that's some REALLY cool software, not just for runing windows on linux, but testing other OSes... I can't say enough good stuff about vmware) Thanks, Shane.
Re: perl vs java
On Mon, 12 Jun 2000, Shane Nay wrote: > If I were to write a new version of the chat engine I wrote, I > wouldn't do it this way. In fact I started re-writing it based on a > sigqueues, and CORBA. Shane, you are a maniac! You wrote a chat server using sigqueues and CORBA? Isn't that like killing a mosquito with an atomic bomb? - Perrin
Re: perl vs java
Now, now...that is unfair. I was referring to writing in pure Perl vs pure Java. Of course, C apis and pre-written daemon integration makes the glue language a moot point (and favors Perl actually). BTW, is select() is still broken in Win32 Perl? It was 6 months ago (I suspect because IO operates differently on win32) so you'd limit your platform too. Later, Gunther At 06:21 PM 6/12/00 +, Shane Nay wrote: >(Somehow I missed Gunther's message, maybe I had a system out for a little >while, I'm replying to Roger, but really replying to Gunther) > > On Mon, 12 Jun 2000, you wrote: > > Gunther Birznieks <[EMAIL PROTECTED]> wrote: > > > 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). > >Hmm..., yes I would. At this point, long before I would write it in >Java. You >know why? Not because of anything in perl necessarily, but actually what you >can do with perl. You see, a perl XS module can take advantage of anything >inside of C. If I were to write a new version of the chat engine I wrote, I >wouldn't do it this way. In fact I started re-writing it based on a >sigqueues, >and CORBA. Corba pre-fetch of everything running around, dump into memory, >sigqueues pick up request from client via httpd protocol (obviously not port >80, this is a special purpose HTTPD engine). Stream out based on pre-fetched >CORBA content. I started writing it, but got distracted by the fact that >I ran >out of money :-), happens to the best of us. > >Java can talk to Corba natively, so the application side talks to the corba >server, and dumps/retrieves it's messages into there. Two threads involved in >the special purpose httpd engine. One that fetches content from the CORBA >engine, the other that streams out to clients based on sigqueus (Similar to >phhttpd, but much simpler). The locking issues on the Corba content is so >yucky I don't even want to discuss it (That's sort of where I left >off). I ran >some benchmarks, and the httpd engine could handle over 1000 requests per >second per server. The corba fetch was really trivial, so the only "problem" >was the communication between the applications and omniORB (Corba Object >Request Broker, really good piece of software BTW, best ORB out there in terms >of speed) > > > > > I did, just a few months ago, and it's working very nicely. > > > > > 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. > > > > So don't do it like that :) My chat engine is a single-threaded, > > select()-based plain Perl daemon (no apache there) that takes http > > connections on a non-standard port, directly from the browser, and keeps > > them open for as long as the browser will. It speaks http on one end, > > and uses the irc-server-to-server protocol to talk to an ircd on the > > other. > >Well, yes that's the easiest way to do it with perl. The other way is to >write >some XS modules which plug into an sigqueue engine, and handle it that way. >Honestly though, if you're going to be writing XS modules to talk to signal >queues, you might as well write the damn thing in c :-). > > > Technically, yeah, select() is arguably ugly, but if you wrap it around > > OO classes for the various kinds of buffers and connections, it's all > > quite manageable. > >Select might be ugly, but it's how nearly every realtime system works. So if >you want a realtime system you need to look into select, poll (ugh), and >sigqueues. > > > Chat connections are very low bandwith, and a single-threaded design > > tends to be memory effective, so I'd expect this setup to handle a few > > hundred simultaneous users easily. If you want more, use a standard irc > > daemon as a hub, and connect several such perl servers to it; if you > > want to have a java applet client too, it can talk directly to the irc > > server. > >Nothing could be more true. Single thread is the ONLY way to go..., anything >other than that is a massive waste of trying to implement. > >Thanks, >Shane. > >-- > __ Gunther Birznieks ([EMAIL PROTECTED]) Extropia - The Web Technology Company http://www.extropia.com/
Re: perl vs java
(Somehow I missed Gunther's message, maybe I had a system out for a little while, I'm replying to Roger, but really replying to Gunther) On Mon, 12 Jun 2000, you wrote: > Gunther Birznieks <[EMAIL PROTECTED]> wrote: > > 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). Hmm..., yes I would. At this point, long before I would write it in Java. You know why? Not because of anything in perl necessarily, but actually what you can do with perl. You see, a perl XS module can take advantage of anything inside of C. If I were to write a new version of the chat engine I wrote, I wouldn't do it this way. In fact I started re-writing it based on a sigqueues, and CORBA. Corba pre-fetch of everything running around, dump into memory, sigqueues pick up request from client via httpd protocol (obviously not port 80, this is a special purpose HTTPD engine). Stream out based on pre-fetched CORBA content. I started writing it, but got distracted by the fact that I ran out of money :-), happens to the best of us. Java can talk to Corba natively, so the application side talks to the corba server, and dumps/retrieves it's messages into there. Two threads involved in the special purpose httpd engine. One that fetches content from the CORBA engine, the other that streams out to clients based on sigqueus (Similar to phhttpd, but much simpler). The locking issues on the Corba content is so yucky I don't even want to discuss it (That's sort of where I left off). I ran some benchmarks, and the httpd engine could handle over 1000 requests per second per server. The corba fetch was really trivial, so the only "problem" was the communication between the applications and omniORB (Corba Object Request Broker, really good piece of software BTW, best ORB out there in terms of speed) > > I did, just a few months ago, and it's working very nicely. > > > 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. > > So don't do it like that :) My chat engine is a single-threaded, > select()-based plain Perl daemon (no apache there) that takes http > connections on a non-standard port, directly from the browser, and keeps > them open for as long as the browser will. It speaks http on one end, > and uses the irc-server-to-server protocol to talk to an ircd on the > other. Well, yes that's the easiest way to do it with perl. The other way is to write some XS modules which plug into an sigqueue engine, and handle it that way. Honestly though, if you're going to be writing XS modules to talk to signal queues, you might as well write the damn thing in c :-). > Technically, yeah, select() is arguably ugly, but if you wrap it around > OO classes for the various kinds of buffers and connections, it's all > quite manageable. Select might be ugly, but it's how nearly every realtime system works. So if you want a realtime system you need to look into select, poll (ugh), and sigqueues. > Chat connections are very low bandwith, and a single-threaded design > tends to be memory effective, so I'd expect this setup to handle a few > hundred simultaneous users easily. If you want more, use a standard irc > daemon as a hub, and connect several such perl servers to it; if you > want to have a java applet client too, it can talk directly to the irc > server. Nothing could be more true. Single thread is the ONLY way to go..., anything other than that is a massive waste of trying to implement. Thanks, Shane. --
Re: Perl vs Java [Now OT]
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
Gunther Birznieks <[EMAIL PROTECTED]> wrote: > 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). I did, just a few months ago, and it's working very nicely. > 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. So don't do it like that :) My chat engine is a single-threaded, select()-based plain Perl daemon (no apache there) that takes http connections on a non-standard port, directly from the browser, and keeps them open for as long as the browser will. It speaks http on one end, and uses the irc-server-to-server protocol to talk to an ircd on the other. Technically, yeah, select() is arguably ugly, but if you wrap it around OO classes for the various kinds of buffers and connections, it's all quite manageable. Chat connections are very low bandwith, and a single-threaded design tends to be memory effective, so I'd expect this setup to handle a few hundred simultaneous users easily. If you want more, use a standard irc daemon as a hub, and connect several such perl servers to it; if you want to have a java applet client too, it can talk directly to the irc server. -- Roger Espel Llima, [EMAIL PROTECTED] http://www.iagora.com/~espel/index.html
Re: Perl vs Java [Now OT]
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 ([EMAIL PROTECTED]) Extropia - The Web Technology Company http://www.extropia.com/
Re: Perl vs Java [Now OT]
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
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]
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]
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] | `-'
Re: Perl vs Java [Now OT]
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]
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]
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: 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
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
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
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: Perl vs Java
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
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
