Re: A Perl vs. Java fight brews

It's been a while since I did any serious Java, but I was in a Java shop at my last job (I left it in 2003).

First, Java may be a good choice if that's what your team knows. But, I wouldn't think of it as an ideal text processing or glue language.

Now for your points:

- greatly reduce the spawning of new ksh processes

If you're going to interface with java language libraries you too will have to spawn jvms or use Inline::Java or something similar from a vendor. If you're going to use Perl's system command, Java has something similar.

- ready interface to unix system services

Java tries to be OS agnostice, so you probably win this point. You won't find core routines like getpwent etc.

- Open3 to control input and output between existing utility programs

Java has sophisticated IO classes, but sophistication is not necessarily a substitute for simplicity. I would take a typical example and code it up in Perl, then ask an oponent to do the same in Java and have a discussion.

- CPAN

Of course, I think there is no substitute for CPAN. But, to be fair, there are lots of Java libraries floating about. It's just the central collection that's missing (and possibly the volume of truly free code).

- associative arrays

Java has hashes, using them is more tedious than in Perl since Perl has built in operators to deal with them. That is, Java will require something like value = hash_name.get( key_name ); instead of the more compact value = hash_name{key_name}. This is magnified for, two or three dimensional hashes, for example compare $myhash{$key}{$key2} to myhash.get(key).get(key2). Further, you'll need to write some String only hash classes for yourself or suffer interminable type contortions (these roads I have travelled). To demonstrate, build up some simple HoAoH or other similar structures and the code to load and access them in Perl and Java. This will be your strongest demo. Don't let them talk you into complex class heirarchies when a HoHoAoH would do.

- scoped untyped variables

They are going to be very skeptical of untyped variables, so they aren't necessarily a selling point.

- flexible choice of procedural versus OO (ksh is only procedural)

This is a sword the cuts both ways for Perl. ksh and other shells are procedural (and, horrors, the procedures must come before code that calls them). Java on the other hand is object oriented only (I call this OOO). Flexibility in a glue system is a big win. Since your original system was procedural, it would be nice to keep that basic structure. Java won't easily allow that. Since your original system had hard to manage data, it would be nice to introduce objects. Shells won't allow that. Perl allows both in spades.

- perl -d (debugger - no such thing for ksh)

Java has a fine system for debugging and profiling, including hooks to write your own debugger. This is a wash in the comparison.

- perl's regexp engine is better than awk/sed's without needing to shell out

Again, Java has regex support, but it is via function calls instead of operators. People think Perl looks like line noise in large part because of the regexes. I think Java looks like line noise because of the parentheses and dots.

- perl's hashes are more flexible and scopable than formula engine's (Formula Engine provides only a single global hash).

Java doesn't have scoping problems. But it does have method only hash syntax and hash elements must be objects. As noted above, this leads to a big win in code simplicity for simple strutures in Perl.

- perl can communicate more effectively with background processes.

Except for the usual verbosity arguments against Java, it is OK in this area.

Phil

p.s. It won't kill you to write in Java, but you might need a better keyboard for the extra typing.

Comment on Re: A Perl vs. Java fight brews

Replies are listed 'Best First'.
Re^2: A Perl vs. Java fight brews by Moron (Curate) on Jul 24, 2006 at 14:28 UTC
Thanks for your helpful pointers. Code equates to money and training would be needed in equal measure for either language. So if all things are reasonably equal technically, management would still be easily swayed if they have to pay say double in man-hours for Java versus Perl to develop the same thing. -M Free your mind	[reply]
Re^2: A Perl vs. Java fight brews by bart (Canon) on Jul 25, 2006 at 11:29 UTC
Java will require something like `value = hash_name.get( key_name );` instead of the more compact `value = hash_name{key_name}`. This is magnified for, two or three dimensional hashes, for example compare `$myhash{$key}{$key2}` to `myhash.get(key).get(key2)`. Don't forget about the need for casting, which makes matters worse. Java "hashes" (Java has many basic hash types, so you have to choose an implementation first) can contain any kind of object, so when you retrieve a value, you have to tell it what kind of object it is, before you can do anything with it. So your nested hash example really has to become more like `value = (datatype)((hashtype)myhash.get(key)).get(key);` [download] where `datatype` and `hashtype` need to be replaced with the real class names for the kind of objects you're using. Are you appalled enough, yet?	[reply] [d/l] [select]
Re^3: A Perl vs. Java fight brews by philcrow (Priest) on Jul 25, 2006 at 13:23 UTC
Don't forget about the need for casting, which makes matters worse... Well put. This is what I was alluding to when I said this in passing: Further, you'll need to write some String only hash classes for yourself or suffer interminable type contortions (these roads I have travelled). You can usually get around constant casting by making some classes of your own that explicitly return String types, then all the casting happens in those classes. But it is still a pain. Phil	[reply]