Re: Perl vs Java - your feedback, not flames

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

>>>>> "Nishi" == Nishikant Kapoor <Kapoor> writes:

    Nishi> Before you jump into it taking one side or the other, let
    Nishi> me clarify a few things right up front. This is not a flame
    Nishi> war. I need to decide on a platform for a decent size
    Nishi> system that I am going to be designing soon, and I am
    Nishi> seeking your input. Yes, I Googled it and have found some
    Nishi> very valuable inputs, but it is nicer to have your peers'
    Nishi> point of view as well.  So, if you have any good/bad
    Nishi> experience(s) with one or the other, please feel free to
    Nishi> share it with me. I'd appreciate it.

    Nishi> I believe, a lot depends on what project (in terms of size,
    Nishi> timeline, domain, etc.) are we talking about here. Here is
    Nishi> an overview of the system:

    Nishi> - Backend IS MySQL

    Nishi> - Programming language MUST be either Perl or Java, on
    Nishi> Linux -- if Perl, it will be with mod_perl -- if Java, it
    Nishi> will be servlets with Tomcat

    Nishi> - App is -- extremely search intensive -- extremely complex
    Nishi> algorithms to be used on server side -- no room for slow
    Nishi> interface

    Nishi> Personally, I am inclined towards Perl because

    Nishi> - it has a faster turnaround time i.e. code, test, and code
    Nishi> again. No compilations.  - with coding standards in place
    Nishi> and 'must document' policy, code complexity, and obscurity
    Nishi> can be minimized.  - it is easily/everywhere supported by
    Nishi> all ISPs. ISP offering Tomcat is hard/expensive to find.

Looks like I get first rant privileges on this one, so here goes.

First, the background.  I have been using Perl since around 1993,
v. 4.036.  Using Java for about a year, mainly hacking other peoples'
code, designing systems for coders to develop, debugging (very serious
debugging!) some real crappy code, etc.

What I like about Java:

- - I like the clean OO implementation.  You don't have issues with
barfing on undefined class methods at runtime.  You don't have issues
of passing wrong/wrong number of arguments to a method.  You have
decent IDEs that can parse your classes and make life easy for you.

- - 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.

What I don't like about Java:

- - Lack of multiple inheritance.  Sure, you can implement interfaces or
whatever, but native multiple inheritance is a major requirement for
any OO system in my book.

- - 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).

- - 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.

- - Non-intuitive.  There's a number of places where, for instance,
auto-promotion and auto-demotion could have been used.  Any reasonably
experienced programmer would expect that return(int) from a method
that returns an Integer would automatically promote the int to Integer
to take an example.  After all, Integer is just a wrapper object class
for int, isn't it?  But no, you have to manually promote the int while
bloodying your head against the wall and cursing the Java designers.

- - Namespaces.  In Perl I can conditionally import library methods and
functions into my main namespace.  That's just not possible in Java.
I find this most restrictive when defining utility functions -- to
access those I have to instantiate an object of the utility class and
call the method from that object.  WTF?

- - 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.

- - 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.

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 :)

Regards,

- -- Raju
- -- 
Raj Mathur                [email protected]      http://kandalaya.org/
       GPG: 78D4 FC67 367F 40E2 0DD5  0FEF C968 D0EF CC68 D17F
                      It is the mind that moves
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/>

iD8DBQFBmueAyWjQ78xo0X8RAtnVAJ9yFYdOsn+U32pRkqebxDF4vaKnnQCeIkXC
K58AmAjfV78PEeC8Kvy7Lck=
=ZqcN
-----END PGP SIGNATURE-----