> >6. Infrastructure. Java has a strong enough infrastructure to build out
> >large distributed systems. Built-in multi-threading networking, and file
> >input/output make Java the best choice for quickly building network-enabled
> >applications.
so far noone has mentioned CPAN by itself. i don't know that there
is a readily accessable source for refereed java droppings nor any
sort of automated java-update mechanism (e.g., -MCPAN). everyone who
has tried to maintain java applet collections has described it to me
as an exercise in pain.
i also don't know of any large, well-coorinated effort to generate
java beans [correct terminology?] for limited-use situations. you
can find modules on CPAN for managing everything from oracle to X10
lamp dimmers. CPAN is also reasonably searchable, via 'i /blah/'
in the CPAN shell. don't know of a way to type 'java -update'
and be in a reasonably well-thought-out environment for package
maintinence.
perhaps one of the better ways to show manglement the upside of
perl is to take some time out and:
(a) find an example of what manglement wants to do w/ java.
(b) find if there is a module that already does it.
(c) ask someone knowlegable how long it would take to write
an application that does and ask them to hack a q&d
prototype for you.
(d) hack something using the module.
(e) compare the times and resulting code for yourself then
present some reasonably slick results to manglers w/ the
times and results.
this will usually lead to something like: hmmm... it took me
around 20 minutes for this code -- stuff on the right side of
the '->' came from CPAN -- here it is, all 6 lines of it. this
java took around 3 hours before the guy didn't have time to
finish it -- he could only write the first 200 lines. oh,
CPAN? that's the perl archive system, to find this module i
went to the web site and ... yeah, it took me around 6 minutes
to install the module. "install blah" did it, with error checking
before the install. no, i didn't hack this -- it's built into perl,
comes with it when we bought <your O/S here>. that's how i keep the
version we got from <vendor> up to date, run perl once every so often
and type "r" to check what we have and what's on the archive.
finding that perl isn't an "addon", that it came from Sun/HP/IBM
as-is is a big help. also makes it easier to upgrade perl versions,
since you can always point out that you aren't "installing" perl but
using the vendor-supplied system to update the vendor-supplied code
in a vendor-supplied method.
identical technique works well for Python or C. the "it took you
how long?" response is an excellent leadin for some carefully crafted
responses on why it only took that long. everyone hocking a language
is telling manglement about "getting it done faster + better" in one
way or another. problem is that above a certian level, people just
don't understand the tradeoffs or questions begged by language mongers
(PM's included). as oracle has proven: whomever gets the correct
messsage out will sell, regardless of their fitness for a particular
use.
i've gotten perl into several places by simply getting things done
for people. the wail of agony when someone gets told it'll take
3 weeks to get THAT fixed is your opening. "oh, sounds painful.
i can take a shot at getting something done for you in the meantime".
do whatever it takes in 30 min using perl and hand it back to the
person. you won't make any friends among the takes-three-weeks
crowd [but they're schumcks anyway]. when it gets to the point that
people entirely bypass the 3-week folks and ask you to do everything
for them someone will ask how you get it all done. explain that
perl came with the O/S and you're just using the standard tools to
get it done faster, etc.
enjoi,
Steven Lembark 2930 W. Palmer St.
Chicago, IL 60647
[EMAIL PROTECTED] 800-762-1582
