Re^3: A Perl vs. Java fight brews

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

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

Replies are listed 'Best First'.
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]

Replies are listed 'Best First'.

Re^4: A Perl vs. Java fight brews
by Moron (Curate) on Jul 25, 2006 at 09:31 UTC

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]