Re^2: A Perl vs. Java fight brews

No they are not Java folk - they are ksh folk whose argument for Java is rather superficial in my opinion, though that doesn't automatically mean they are wrong, of course. But thanks for continuing with your analysis! At least it warns me that I have to find out how to code these Java features for the Java vs. Perl benchmark tests - what I forgot to ask is what about comparative development time for a typical routine in Java vs. Perl - such costs will also have to be taken into account by management.

As I understand it, Java uses its own virtual machine - isn't that going to be slower than perl's use of the real machine via C, for example when using IO services?

-M

Free your mind

Comment on Re^2: A Perl vs. Java fight brews

Replies are listed 'Best First'.
Re^3: A Perl vs. Java fight brews by philcrow (Priest) on Jul 24, 2006 at 14:24 UTC
If the folks are old shell script hands, I would pitch perl as a better shell language. In particular, if the project is ported to perl from the shell scripts, it will probably proceed faster than if it is coded from specs in either Perl or Java. Off the top of my head guesses about performance, aren't going to help you. Run some timings of typical things your system does. If Java wins I'll be surprised, but if the margin is large I'll also be surprised. Java has had a lot of optimization attention over the years, I'm guessing some of that paid off. Phil	[reply]
Re^3: A Perl vs. Java fight brews by GrandFather (Saint) on Jul 24, 2006 at 19:44 UTC
How important actually is raw performance? Generally algorythm changes will make much more difference to performance than the difference between two somewhat similar languages. If one language supports a better technique more easlily than the other then that may be important, but raw speed differences between Java and Perl are unlikely to matter much for most applications. Can you show us some sample ksh? Is it more like Java or Perl, or so completely different that it doesn't matter? Remember that the important thing up front is how easily your team will be able to retrain to use the new language efectively. That can be helped a lot if there is at least one person who is competent using the new target language. Everyone flapping around together generating poor code and making bad implementation choices while learning the language is likely to cause problems for much longer than it takes everyone to become competent with the new language. DWIM is Perl's answer to Gödel	[reply]
Re^4: A Perl vs. Java fight brews by Moron (Curate) on Jul 25, 2006 at 09:31 UTC
Good point - to answer the question, the ksh could be said to be more like Perl than Java, but sadly to take advantage of that would be an extremely bad idea: To gain all the advantages for Perl I would want to claim, the Perl should be written like Perl, taking all the advantages I and others have pointed out. If I were to encourage the fastest conversion from ksh to Perl, this would produce very bad Perl code indeed. To give an example, there is code that uses gdate to produce dates in the format YYYYMMDD and a program called add_days that prints the date that results from adding or subtracting a specified no. of days. Rather than shell out to either of these programs, the Perl implementation should have its own date routines that conform to the application system standards while transparently using CPAN modules as appropriate without any shelling out taking place. The last thing I would want to do is have some manager planning a code conversion that makes the Perl code shell out just because it was the shortest and cheapest route from the original ksh code. -M Free your mind	[reply]
Re^3: A Perl vs. Java fight brews by rodion (Chaplain) on Jul 24, 2006 at 20:01 UTC
Since you're mostly porting from ksh, can you find a mostly shell-ish example that ports nicely and readably into Perl, then port it into Java as well. It's good to be able to say "We have a fair amount of code like this, and look how similar it looks in Perl. It just has some of the anoyances cleaned up. The Java for this looks pretty awkward." It has to be representative of a fair amount of code, but it doesn't have to be representative of all the code for your point to be important. People care about the parts Perl will make nicer, and the parts Java will make nicer. You want to do a good job of presenting the Perl side, for your body of code. The things Perl takes from shell scripting should help a lot. A good example is powerful in guiding thinking.	[reply]