"Selena Sol" <[EMAIL PROTECTED]> wrote:
> I wil not participate in a Java versus Perl discussion here because I
think
> it distracts us (me) from advocacy. There is no way to argue this to
ABSOLUTELY. A language war is neither appropriate nor profitable for
anyone.
But - I do want to dig into your points laying out what about Java makes it
superior to Perl for enterprise applications. My goal is to understand
these
strengths and to determine if these are areas that can be easily improved
during the natural development of the Perl platform, or whether there are
areas where we can freely admit, without inner feelings of self-betrayal,
that Perl is just not an appropriate choice.
> When I speak of Java here, I mean the J2EE platform.
This simple statement is very important. The Java community has something
called "the J2EE platform". It's a big agglomeration of Stuff that, taken
all together, provides a powerful toolkit for this type of software
development.
There was a debate at the perl5-porters get-together at TPC discussing the
pros and cons of creating some sort of approved bundle of "standard" Perl
modules. Should the standard set that comes with a vanilla Perl
installation
be expanded? Should their be several different bundles available? How
would
you version-control such a thing, when the constituent modules are
constantly
changing and improving?
I'd like to pursue this line of thought further - perhaps on another list.
> 1. A controlled/restricted environment (not more than one way to do it,
> strong typing, better OO support) better protects the enterprise from
> variations in coding standards. In my real-world experience, it is easier
> to share share beans in Java than it is to share modules in Perl. It is
> possible in Perl, and lots of organizations do it...it is just harder.
Hm. Some of these are religious points. Let's not go there.
But your remark that sharing is easier in Java and Perl is troubling -
in the open source environment, surely sharing is of paramount importance,
and it's vital to do anything we can to make sharing as easy as possible.
> 2. The business rules can be more easily isolated from application logic
and
> look and feel because the environment is built to help programmers to it
> that way. Againl it is possible to do this in Perl, just more prone to
> dsitraction. Few organizations make it past one or two generations in
perl.
> Perl 'seems' to be better for rapid prototyping rather than production.
This is a interesting twist on your OO point above. I think what you're
saying is that encapsulation is easier to do in Java than in Perl. Or,
that Java makes it harder *not* to do it. This aspect of the Perl language
presents barriers to building large applications.
> 3. Enterprise feature libraries like double byte support etc...
Religion again. My Perl Unicode module is better than your Java Unicode
package, blah blah. If there are specific technical domains where one
language or platform is stronger than another, that's something that I
consider an "easy" problem to solve - someone just needs to write code.
Unicode support in Perl is one area in particular that has been getting a
lot
of attention recently. I generally trust than enterprising module writers
will
eventually fill in any technical gaps that come up.
Summary:
For Perl to be considered a valid alternative to Java for enterprise
application development, it needs:
1. a Platform. Something like J2EE. A bundle of stuff, well packaged,
that is specifically useful for building this type of software.
2. better shareability of components. Something more/different than
CPAN provides today.
3. improved facility for guiding disciplined development processes (e.g.
strong encapsulation) for teams building large applications over long
periods of time.
Now we're getting to something actionable. If you believe that Perl has
potential in the enterprise software arena, and that these are the barriers
that are impeding progress there, then there are clearly some things that
we can do about it.
-Jason
