Re: major advocacy help needed

[Steven Lembark]

-- Gabor Szabo <[EMAIL PROTECTED]>



Considering that maybe your boss, being a Senior VP, isn't very sensible
to the language's specs, I'd try a more high level approach:
... and the VP will respond something like this:

- Perl is an Open Source language with world wide support of a large
enthusiastic community independent from 3rd party corporate interests
It does not have a "father". What if those people lose interest. What if
we have a problem and those kids are not interested in fixing it.
We cannot afford to invest in something so risky.
Seems unlikely when NASA, DoD, NSA, Dept. of Treas, IRS,
and the Federal Court system use it heavily. Oh, and did
I mention the Federal Government?
One good example is the Federal District Court calendaring
system, which is a 1.6M (no typo) line perl5 package.
If noone maintains it and the current version works for
you then it isn't an issue; if you need something fixed
then hire someone to fix it. You'll get better response
from an employee/contractor than a large vendor for
fixes in most cases anyway.
- A lot has been done through the years to enrich the language (CPAN)
I can buy the same things for Java.
Where can I buy support for those libraries on CPAN ?
What about copyright issues ? I'll need to ask our lawyer ($200/hour) for
every library we download.
You probably can buy them for Java. You can buy them for
Fortran77 and Cobol also.
But will they be tested equally well as modules that are
used in millions of programs worldwide every day?
For that matter, if you buy them and need a change, how
do you modify the Java lib's?
- It's no spring chicken.  Perl has been around for many years, and it's
used because it's good, not because someone sold it as vaporware very
well
Perl is an old langugage, does it have objects anyway ?
Yes, and unlike the ones in C++, Java, and Python they
actually work. OO programming is based on the idea that
classes define behavior. The "object" is then some data
with behavior applied to it by the class.
The main problem with C++ and languages derived from it
is that the only place to put "class" definitions in C
was a struct, which defines data. Thus we got diamond
inheritence, single inheritence, etc.
There are really effective, simple, effecient -- both
in computer and development time -- methods for handling
data that these languages cannot use becuase re-defining
a class requires copying. In perl you can re-bless an
object to manage its behavior without desroying or
duplicating an existing object.
The other advantage Perl has is that its data types are
high-level OO, instead of low-level. The perl "scalar"
could also be called a strongly typed, encapsulated,
polymorphic unit variable but "scalar" has fewer syllables.
Tell me, quickly: what size integer is required to store
the offsets into the DNA of m.musculus hemogloben? The
average household income for Detroit? Your last database
dump?
With Perl you don't care: the language handles it gracefully
for you at the most effecient level. With C++ and friends you
end up with container classes, an extra level of documentation
(and bugs, and sync points in parallel code, and maint.
programming, and... ) just to get generic storage.
Which is why Perl's strong typing is at the usage level not
the storage level: The polymorphic object will gracefully
handle most conversions. The ones that make no semantic
sense are disallowed (e.g., $hash->[$offset] or $ary->{$key}).
The syntax is rich and flexable enough to allow effecient
programming without fighting low-level types.
- Being also free, in case your boss changes his mind later, there is no
risk of regretting some big licenses investment
So you say it might not fit ? I want to decide on our language of choice
NOW ! And yes, BTW what you pay is what you get.
Then I'll sell you a copy of perl for $1_000_000. Hell,
for that price I'll even sell you Java :-)
The main expense in Java licenses is not the language but
the upgrade/maint/support contracts. If Sun stopped
maintaining and supporting completely then the language
would be worthless.
You can buy support contracts for Perl from several reputable
compaines. The difference is that you have some controll over
the situation: you know what they are charging for and can
switch providers if you don't like it. With the licensing
scheme you "pay" for the license and the support sort of
dribbles down as a byproduct. At that point it's hard to go
back and say "Sun, your support stinks!", all they'll do is
say "fine, you bought a license".

- Perl is quite lightweight and tipycally does not need big hardware or
expensive application servers to run, like Java does
Hardware is cheap, it is not relevant. Does Perl have such a wide choice
of Application Servers ?
Moreso than Java. And you don't have to worry about
differences between Sun, IBM, and Microsoft versions.

- If finding Java programmers is easier, then finding bad Java
programmers also is. Quality and quantity differ.
Perl scripters can't even read each others code.
Bullshit, otherwise CPAN wouldn't exist.

You can always hire idiots, or let capable programmers
get away with not documenting their code. I have worked
with F77, Cobol, Basic, C, and Perl that were perfectly
readable or spagetti.
You want unreadable? Try 390 assembler from the 1960's
that's been modified by 8 generations of programmers.
Now THAT's a spicy meatball...
- A bad OO Java architecture has tipycally tragic performance problems
and is hard to reengineer. A poorly implemented Perl architecture is
more easily tuned and fixed
Perl is an interpreted scripting languge. It is known to be slow.
Nope. Perl is just as compiled as C or Java.

Normally just as fast.

Helluva lot easier to embed hand-crafted C for the
few cases it isn't fast enough via Inline than it
is with Java.

- EAR deployment consumes too much development time
Installing 50 modules from CPAN is a nightmare.
I can automate CPAN quite nicely at the shell level or
via the CPAN module -- which is written in perl and
intended for easy access to the language.
- Perl also runs everywhere
Does it run on mobile phones and on PDAs ?
YUP.

Question: how many of your people will be using this
for processing on a cellphone?




--
Steven Lembark                               2930 W. Palmer
Workhorse Computing                       Chicago, IL 60647
                                           +1 888 359 3508