>> Selena wrote:
>> I find the Java libraries built in to Java to be FAR more abundant,
>> integrated, and easy to use.
> John replied:
> Perhaps, but most of that code is necessary simply to get a
> programming environment roughly equivalent to core perl.
Hmmm, I am not convinced of that. How is RMI, JDBC, and JMS roughly
equivalent to core Perl? Granted that JDBC compares to DBI, but how is
messaging and remote control of ojects supported in Perl?
How about threading? How about built in support for non-English character
sets? GUI development? How about an environment that "helps" developers
write object code that can live productively after the developers leave?
All these things come for free with Java.
In Perl, either they don't come at all or they are not "built-in" to the
core distribution like they are with Java. And thus...you need to roll your
own or use CPAN.
Now if, as an organization, you use CPAN, how do you support the code? What
if there is a security hole in a CPAN module and the author is in the middle
of final exams? What if you need to extend the module with customized
features?
The fact that these modules are not supported by Perl Inc. means that you
may feel a bit....hanging over the edge. It is not a secure place to be if
you are a CIO. If you then look at Java which has a more
centralized/controlled library, you can at least be sure that the core is
supported by Sun (although at a high cost).
Also, I do not think that most of the Java code is required to match
Perl....and I don't think it does match Perl in every regaurd.
For example, string manipulation in Java sucks. And as Adam mentioned, Java
comes with slower time to market and the developers are usually more
expensive. But, I think that we as a community should recognize the
strengths of Java and weakness of Perl.
That is, it is okay to take shots at Java when Java really lags...but in
terms of library support, I think this is where Perl needs to buck up (catch
up) a bit.
>> Selena Wrote:
>> Also, too many people
>> duplicate work with modules that are essentially identical.
>John replies:
> Would you prevent them?
Definitely no. I believe that this organic mode of development is far
superior to any tightly controlled mode.
HOWEVER....
The organic mode, though technically superoior may not be superior in the
marketplace. The marketplace, not the university, is where languages are
faced with survival of the fitest and the rules of the game are often more
about marketing and cash flow management than they are about technology.
We need to find arguments, perhaps similar to those of open source, that
make the organic mode of production in Perl seem better to a business-minded
client. Not just seem. Our mode MUST be superior from a business
perspective.
>> Selena wrote:
>> CPAN could be a big plus for sales calls....but somehow, it needs to be
>> packaged right.
> John replied:
> CPAN can be packaged any way you want. It's just an Open repository.
Well perhaps in its infinite diversity, it loses its tangibility and clients
fail to uderstand its benefits. When I say package, I mean that we need to
come up with a pitch that could convince a client in 5 sentences why CPAN is
great.
