in reply to
A Perl vs. Java fight brews
I'll state up front that I would choose Perl for the task you've outlined. But then I'm responding to a post on perlmonks, which might reveal a little bias.
One question I'd ask you is: do any of your colleagues have Java experience? If nobody has any Java experience but one member of the team is proficient in Perl, then that makes a big difference. If on the other hand 4 out of 5 team members have used Java, it's going to be a lot tougher to sell Perl.
greatly reduce the spawning of new ksh processes
If I understand the requirements correctly, I think Perl would be a better choice in this area because it's possible to do a lot of shell type operations directly in Perl code.
ready interface to unix system services
Similar to the above, Perl is much more "unix-ish" than Java. An example of something that is much more difficult in Java is manipulating file permissions. There is no chmod
Open3 to control input and output between existing utility programs
If you mean using pipes, I can't comment because I've never done that with Java. What I can say is that file I/O is a lot more work in Java compared to Perl. In Java you don't just open a file and print $fh "foo"
, you have to deal with a bunch of confusing APIs. Similarly, there is no @lines = <$fh>
in Java, and reading from files involves more, different, confusing APIs.
This is a clear win for Perl. There is no equivalent repository for Java. I think the amount and quality of available Java libraries has increased a lot in the past few years but it still takes a lot more time to find and evaluate the options.
There are several hash-type structures available in Java. You'll find them harder to work with than Perl's hash though. First, you need to decide whether you need a Map, HashMap, Hashtable, TreeMap, etc. You can store just about anything in these structures, as long as it's an object. But then when you go to get something out, you'll need to cast it back to the proper type of object before you can do anything with it. Then there are the sorting issues. Some of these collections can't be sorted, period. Others can be sorted, but if you want to sort in an order different from the "natural order", you'll need to write your own Comparator class. This is a great example of where I gripe that I wish I was using Perl instead.
scoped untyped variables
Scoped, yes. Untyped, sorry, Java don't do that.
flexible choice of procedural versus OO (ksh is only procedural)
Sorry, Java is OO only.
perl -d (debugger - no such thing for ksh)
I've never used the Java command-line debugger, but if you use an IDE like Eclipse, the debugging is actually pretty cool.
perl's regexp engine is better than awk/sed's without needing to shell out
Starting with JDK 1.4, Java has native regex support. There are also some third party implementations like Jakarta ORO
and Jakarta Regexp
. Like most things in java, using regular expressions requires more code than in Perl. I recommend Mastering Regular Expressions
, it has good coverage of the available options for Java. Also, I've found cases where I was unable to port a regex that worked in Perl to any of these.
perl's hashes are more flexible and scopable than formula engine's (Formula Engine provides only a single global hash).
See my comments above on associative arrays.
perl can communicate more effectively with background processes.
I'm not sure exactly what you mean here. If you mean getting information about processes that you didn't spawn, the Java security model will probably make this difficult.