At 01:25 PM 8/12/00 -0600, Rodney Clang wrote:
>P.S. I think there is a large range of topics in applied usage that could
>be written for new titles. In the Java and VB world, I see titles like
>"Business Objects", "Enterprise Database Programming", etc. and this is
>an area I would *love* to see books on Perl appear.
This is where I would like to see *products* using Perl appear. (cf my
earlier rant on untapped niche market for Perl.)
I realize we're all looking at different appendages of the elephant here,
and that in some parts of the world there is nary a hint of a threat to the
dominance of Perl. Realizing that all I can contribute is the odd tusk or
toenail, here's another one FWIW: large client, big enterprise data system
running on Oracle. I built a user management system for some internal
business services from Perl/DBI using CGI for UI. The DBA team then built
Java objects more or less paralleling mine because Oracle included Java and
anything they wrote would interface with tons of products for, e.g., tying
directly to applets, etc.
Now other business services are using those objects and the DBA team is
making noises about restricting access to the database for people outside
the team to go through that object layer - no more SQL they haven't
written. Of course I've been preaching the benefits of multiple language
bindings, rapid prototyping with Perl, etc. If it hadn't been for me Perl
would have been expunged from that system long ago. But it's a rear-guard
action.
This is what I think are the major factors stacked against Perl:
o Java is bundled into key products like databases and browsers. Rather
than just the language being shipped with an O/S, major enterprise products
have exceptionally well integrated Java libraries. Marketing issue.
o No binary compiled form for shipping products. Technology issue,
hopefully addressed in Perl 6.
o How to ship products using third-party libraries? Any significantly
complicated product will use many CPAN modules to avoid reinventing a bunch
of wheels, and if you're lucky it will go so far as to specify which
versions of those it requires. You can be sure that one of them will be
updated a couple of weeks later. Does the system engineer (a) upgrade the
module and hope that the regression tests are good enough, (b) ask the
application author whether it's okay, (c) freeze the module version used by
that application and maintain separate copies for each app using a
different version each time this happens? Most of us probably check the
README to see if any backward compatibility was broken, run a test suite
with the new module, then push it out. There are places where that just
isn't enough. Larry can tell you plenty about how hardware and software
freezes dominate operations at JPL, for instance. Quality control and
integration issue.
--
Peter Scott
Pacific Systems Design Technologies
