I’d say Java has better tool support (debuggers, IDEs, refactoring, etc.) than Perl.

It also needs them far more badly than Perl. Not only is Java generally more verbose, but it is deliberately designed to prevent you from abstracting your code past a point. As a result, large Java systems grow quadratically with the number of interacting parts in the system – and without tools, well, you aren’t exactly lost, but it’s going to be really unfun.

(I was going to say that the only thing Perl is still missing is a really good graphical debugger for people who prefer working with them (I prefer logging, but I acknowledge that it’s not the same for everyone), but then I remembered Devel::ebug, and now I’m not entirely sure.)

So to the OP, I would suggest reimplementing some small but significant portion of the system in both Perl and Java, and see how large they grow. It is a demonstrated fact that bug counts are invariably linear with the size of the codebase, even though noone has a deep understanding of why; it is also common experience that maintenance effort grows faster than linearly with the bug count. Java solutions almost always cost more and take longer than ones written in a more expressive language. I’m not even advocating Perl in specific here – pick Python if you want to, just stay away from the Java albatross.

Makeshifts last the longest.

It also needs them far more badly than Perl

No argument from me there. I'd still like a good refactoring tool for Perl though.

I'd still like a good refactoring tool for Perl though.

Have you checked Perl::Critic?
It can't automatically restructure your code (BTW I don't trust such tools), but for such actions a simple text editor is often sufficient.

Ciao, Emanuele.

Java has had regular expressions for years. They've even implemented the named capture syntax that we won't have until perl6.

Though regex support in Java was introduced several years ago (but not that many: JDK 1.4 AFAIK, 2002 circa, if we mean the java.util.regex package), it still doesn't offer advanced things such as match-time code evaluation, match-time pattern interpolation and conditional interpolation.

So, for example, with a Java regex you can't build a recursive pattern (to check for instance if the parentheses in a text are balanced), while in Perl you can ;-)

Update

It can also be interesting to see how more verbose Java regexes are compared to Perl regexes.
Here is a simple Perl example:

my $pat = qr/a+b/;
my $res = "aaab" =~ $pat;
[download]

and here is its Java counterpart:

import java.util.regex.*;
Pattern pat = Pattern.compile("a+b");
Matcher mat = pat.matcher("aaab");
boolean res = mat.matches();
[download]

Really, the above 2 last lines could be substituted by the following somewhat shorter code:

boolean res = pat.matcher("aaab").matches();
[download]

but if you don't explicitly instantiate a Matcher object, you can't have several things such as match, prematch, postmatch etc. which Perl gives you for free (through the various predefined variables $&, $`, $' etc.)

Ciao, Emanuele.

Java has had regular expressions for years. They've even implemented the named capture syntax that we won't have until perl6.

I didn't think they were as flexible as the Perl ones (e.g. using composition to build up regexes from component regexes, //e, etc.)?

However I freely admit I could be wrong. It's been several years since I've done any serious Java and I'm too lazy to look things up :-)

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?

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

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.

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

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