RE: Perl vs Java - your feedback, not flames

Thanks to all those who responded. Honestly, I was not expecting so many responses, so quick. Thanks again.

Here is some more info that I should have mentioned earlier.

- The only IDE we plan on using is (X)Emacs, if you consider it an IDE. I have not evaluated Eclipse yet but from what I have heard about it, it qualifies to be a strong candidate too.

- Most of the members in our team (4/5) are freshers, and much more comfortable with Java than with Perl. They have already given their preference, which is Java. So, their learning curve and their happiness is an important factor too.

- Management is inclined towards Java, because Perl is a 'difficult' language and 'it is hard to find good Perl developers', whereas you can find Java expertise - anywhere, anytime. Fresh graduates and even interns are well-versed in Java, and that takes some pressure off of maintaining the system ever after.

And now, here is my follow-up, point by point.

> -----Original Message-----
> Looks like I get first rant privileges on this one, so here goes.

Pleasure is all mine :-)

> - - The other nice thing about Java is its platform-independent GUI
> development model.  In your case I doubt if it'll be any use, since
> you're doing server-side, but for clients it makes a lot of sense to
> code once, run anywhere.

Team members would like to be able to 'duplicate' the entire 'development system' on their 'home system' so that they can do whatever they want to with it without disrupting others, which I think is very nice. However, 'development system' is a Linux based whereas some 'home systems' are going to be Win* based. How far along the two systems cooperate with each other, would be an interesting feature to observe.

> - - Speed.  Man, that really sucks.  I've seen large, multiple-CPU
> systems crawl to a grinding halt when running complex Java code.  Java
> also tends to be a memory hog.  I've never faced those sort of issues
> with Perl, even in Web applications where I don't use mod_perl, just
> plain old CGI (so the Perl interpreter gets loaded on each hit to a
> page).

Most of our server side processing is going to be done in 'batches'. Models will be 'cooked' for different algorithms ahead of time, and only 'fetching results from DB' will be done when user interaction occurs (minimal server side processing at run-time).

To give you an idea of our 'models', it took us 40 minutes to build the 'base' model on a Pentium 4 with dual CPU and 2GB RAM. Afterwards, it was updated incrementally every hour, which took a few seconds. It was developed in Perl, but I think Java would have fared equally well since a few minutes difference would not have mattered much.

> - - Restrictiveness.  Lack of flexibility is a major issue 
> for me.  Perl
> gives me the option to make mistakes if I choose, Java doesn't.
> Perhaps it's a function of temperament, perhaps of experience, but I'm
> strongly opposed to systems that tell me I must program in a
> particular way.

You are an experienced developer. Inexperienced developers tend to like systems that 'guide' them to write 'correct' code.

> - - String handling.  I find that most apps have complex 
> string handling
> requirements.  In Java I just compromise and, for instance, loop
> through a StringTokenizer to access my fix-delimited string components
> whereas in Perl I have the option getting all tokens into an array and
> passing it around, sending it over a SOAP call or writing it into a
> file.  Oh, and regular expressions!  Haven't seen a language to beat
> Perl's regular expressions yet!  With Java REs are an add-on package
> (at least in 1.4.2) -- you have to install java.util.regex on each
> system you want to run your application on.

Definitely a plus for Perl, but latest Java seems to have incorporated some really neat string handling (I heard, can't confirm), and installing packages, I think, should be a manageable issue.

> - - Non-free.  My biggest issue with Java is that its past, present an
> future are controlled by a single entity: Sun.  They decide which
> features go into Java and which don't.  They don't permit you to
> modify their code and redistribute it to your customers.  They don't
> indemnify you against patents in the code that they own.  I personally
> would never choose a language for which I couldn't be *SURE* that I
> could keep maintaining the version in the future or hack required
> features into newer versions if they were dropped.  Or just fork my
> own version of the language with original code if the original
> developer decided to start charging for his efforts.

This is probably not an issue for us since we have no plans to modify either Perl or Java. Having them available on Linux for free is one very big issue, and both take care of that well.

> You must have guessed by now that I'd choose Perl over Java for a
> project with my eyes closed.  What should you choose?  You decide :)

Thanks again. You are very helpful, as always.

Regards,
Nishi