Oh, I also wanted to list as one of my wish list items that any perl based
environment would facilitate a distributed environment in which the look and
feel for my apps were stored on a web server and the biz rules on an app
server which could both be farmed and in separate DMZs. This is simple in
J2EE and one of the very first requirements whenever we go into an
enterprise environment.
By the way, this is again where web services can be impoirtant. Currently,
distribution in J2EE is RMI-based and distributio in COM is DCOM based. Both
of these are proporietary standards. I want an inspectible protocol like
SOAP for my component communication if possible.
-----Original Message-----
From: Selena Sol [mailto:[EMAIL PROTECTED]]
Sent: Saturday, August 25, 2001 2:06 AM
To: [EMAIL PROTECTED]
Subject: RE: Let perl be Perl (was... perl vs php)
> Jason wrote:
> 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.
This is a wonderfully reasonable perspective to take. And as I discuss some
of the things you wrote, I want to remind everyone that I am on the Perl
advocacy list here...I am not a JavaBigot...I am just trying to raise issues
that I think Perl can benefit from.
Also note that I have had this discussion before and it turned out sour, so
I may quit it if it does not look fruitful :) However, I feel that maybe I
am crystallizing my own thoights better this time for myself....
>> Selena wrote:
>> When I speak of Java here, I mean the J2EE platform.
> Jason wrote:
> 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?
Actually, I think this may be part of the definition of J2EE that led me
into such trouble the last time I talked about this here.
While I do think that having a huge amount of standard stuff in the vanilla
distribution is a benefit of Java, I think that to intermediate developers,
the fact that CPAN is only a click away makes Perl's alternative attractive
enough. Further, in an open source development model, the CPAN style is
perhaps more appropriate. You lose some continuity and focus, but you gain
wonderful chaos that makes Perl, or any open source project, so vibrant.
What I like about J2EE is that it provides enterprise components that are
necesary on large distributed projects.
For example, I want to see a perl architecture that supports an application
server that is built to "help" me and my developers create and register
distributed business objects that can be served in a scalable and secure
manner through a simple interface.
This would be far more efficient for a large organization with a constantly
revolving developer stream that must manage many large projects with quick
timelines and strict business requirements. When my business rules change, I
want to change my rules, not all the applications that use them.
While I like Perl for its ability to create small, quick scripts, I cannot
leverage these scripts across an enterprise without very, very, very careful
attention and planning. J2EE, on the other hand, is built with the
enterprise in mind and has a structure which, like the Java language itself,
shepherds developers towards good coding practice and good, reusable design
patterns.
I like the strict pragma and our developers use it. I wish Perl had more
built in features to help shepherd development.
I also want my business object interface to be made available to third party
entities through SOAP-based web services. EVERY client I have in Asia and
Europe is currently facing the problem of inter-organizational cooperation.
Whether it is Web services or something else, we need a standard through
which our applications can communicate across companies.
I also want caching functionality provided by my application environment. I
could use single sign-on. And I could use a host of other features that an
enterprise application environment provides.
I believe that all of this is possible with wise use of many technologies
within the perl community such as apache/mod_perl, template::toolkit,
etc....but it is certainly not easy to put together and there are no built
in controls.
>> Selena said:
>> 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.
> Jason replied:
> 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.
Sharing business objects in an enterprise, not in the whole world :)
But, that said, like I mentioned in another post, it is not that the java
world does not have as many non-SUN modules as are in CPAN. There may not
be one all-encopmpassing archive, but there are not that many.
By the way, which ones are religious.
I imagine that nobody disagres that in Perl there are more ways to do the
same thing then in Java. I also imagine that nobody disagrees that there is
stronger typing in Java. The thing about OO...well I can see that some
would say Perl OO is better....so...I guess that could be considered
religious...but I would like feedback cause I want to atack my own beliefs
if they are in fact not factual.
>> Selena:
>> 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
>> l.
>> erl 'seems' to be better for rapid prototyping rather than production.
> Jason:
> 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.
That is right. This is in fact what I am saying. Encapsulation is supported
not just by the language but by the environment. The crucial point about
J2EE is not that it is a standard, but that it provides an environment in
which to build applications.
This environemnt, though restrictive, helps large enterprises (not
developers) write better code. That said, a good Java guy can break out of
the prison just as a great Perl guy can write enterprise-ready code.
It is just that both of those programmers are so rare that they needn't be
mentioned when making decisions about what technology to choose for an
enterprise project.
>> Selena said:
>> 3. Enterprise feature libraries like double byte support etc...
> Jason said:
> 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.
I think that you are right, but I think that from my perspective, being in
Asia where chinese and thai language support is important on many projects,
Perl is not yet there. The fact that it is there in Java is part of the
reason why Java appeals to the enterprise. Multilingual support is the
kind;ve problem that an enterprise would care about and is not necessarily
the type of problem that the majority of developers would care about. That
is why the writing of these great modukles in Perl is slow.....we have to
wait untril someone who can do it, needs it. In Java, thjese types of
modules are written cause if they are not SUN sells less stuff in Asia.
> 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.
I really liked how you summarized the points into action items. I think it
is not quite right, but your format turns a wonk wonk discussion into
something that can be used by the advocacy list. I will try to follow your
leads in future wonk wonk discussions.
For Perl to be considered a valid alternative to Java for enterprise
application development, it needs:
1. to not lose what makes it unique and special. So whatever new shapes it
takes on should be evolutionary, not revolutionary.
2. a Platform. Something like J2EE that provides components that
enterprises care about such as an application server, business rules engine,
caching engine, or single sign on server.
3. improved facility for guiding disciplined development processes (e.g.
strong encapsulation) for teams building large applications over long
periods of time.
Anyway, I am fine with CPAN...I think it is pretty darn cool and has been
getting MUCH more usable in the last few years. My issue about sharing is
not so much about sharing archived code between developrs but sharing live
business components between applications.
> Jason
> 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.
I definitely think that Perl has potential in the enterprise space and I
want it to break into that niche both because I think it would help me and
my company and because I also think it would help Perl. With that said, I
take to heart the concerns that people have had on this list that Perl
CANNOT lose its spirit. I would rather continue to use Java in the
enterprise market as I currently do then to have Perl lose its luster.
