Asking how one would fix Java is akin to asking how one would fix Perl: you're going to get a lot of opinion, much of it based on personal beliefs (rather than realities) and personal circumstances.

To me, the major difference between the two is scaling of productivity vis-a-vis programmer performance. In Java, it can be easier to get a large team of mid-level programmers to build large systems due to a variety of language features that many in Perl object to:

• Compile-time enforcement of exceptions (which are sometimes stubbed out, negating that benefit)
• Strong typing which alleviates certain classes of errors (adding apples and oranges, for example).
• Cleaner separation of class and instance data and methods
• Signature-based method overloading
• Easy to enforce data encapsulation
• Easy to enforce private methods

All of the above can be handled in Perl, but not as cleanly or easily. Since Perl allows one to play fast and loose with terser code, you can have a smaller team enjoy much greater productivity, but you have to have a higher caliber of programmer who has a more ingrained understanding of why the above might be beneficial.

One problem with Java really is the length of programs. To build those larger systems, you have a need for a larger group of programmers. This means more management, more communication, more strain on resources, etc. As a result, you hit the problem of diminishing marginal productivity much faster.

That's not a clean win for Perl, though. Theoretically, having a smaller number of programmers with the same level of productivity means fewer opportunities for miscommunication, lower strain on resources and rapid development. While this can dramatically reduce costs, how do you identify a Perl programmer who has the necessary ability to be productive in a large team? Simply knowing everything about the language isn't enough. You have to know how to design systems and how to play well with others. These are not trivial tasks and many managers, while great at managing technical people, may not be great at evaluating technical people. One bad Perl programmer can churn out a lot of awful code which can be very expensive to fix, thus negating the benefits of going with Perl.

Many of these issues may be dealt with when Perl 6 is widespread, but we still need to build products now. This means that for a management team investigating alternatives, Java may not be a bad choice. Personally, I don't care for the language, but that's because I work differently.

And some gripes about Java (feel free to correct me as it's been a long time since I used Java):

• Immutable strings limits its suitability for intensive text munging due to the need to repeatedly copy strings and eat up memory.
• Give me print formats, or give me Perl!
• Primitive types were poorly designed and shouldn't have been put into the language in their current incarnations.
• Libraries keep getting moved into the core which are not always fully backwards-compatible.
• I don't need a nine-megabyte "hello world" executable.
• Arrays are too simplistic and force awkward work-arounds (and collections cannot contain primitives!).

Mind you, I can easily come up with a similar list for Perl, but I know Perl's limitations, so they don't bug me as much. Naturally, that should not be taken as a "Perl is better than Java" statement :)

Cheers,
Ovid

New address of my CGI Course.
Silence is Evil (feel free to copy and distribute widely - note copyright text)