>> Just put the script in there and tell Perl where to find it.
>> This solves the installation problem without raising IP issues.  More
>> to the point, it doesn't require significant original engineering.
>> Genuine perl-code-to-binary compilation is, to date, an unsolved
>> problem.  By comparison, a minor hack to locate source code that lives
>> in $^X is the very epitome of elegance.

There's more worth advocating in perl than just the language - I hate to sound
like a PHB, but "Perl the environment" contains a lot worth advocating to PHB's.

I work inside an investment bank and I have a number of Perl scripts that run in
various key systems.

If I can distribute these as a single executable (possibly requiring one or two
dynamic libs), then this makes situations such as DR much easier as having Perl
installed is no longer a pre-requisite.

At the same time, I'd prefer to be able to get the source back out - I've lost
track of how many programs we have in the bank which we've lost the source for.
This also makes it much easier to show auditors and regulators that we can show
what a system is doing, and prevent it from being "interfered with" by staff
inside the bank.

A mod to the PerlApp / perl2exe type programs to keep the source, optionally
encrypted with a password would give Perl a huge win over current script
solutions (ksh, winbatch, WSH) and over compiled solutions (C/C++/VB) by
combining ease of deployment with secured-source security with
easy-source-retrieval bonuses too. The password encryption of source is NOT for
IP reasons, but to show that I can deploy an app that logs into a database
without overtly revealing the username and password it uses - banking
regulations force us to prove that certain Chinese Walls exist within the bank.

The size of the resultant binary image is practically irrelevant - we're a bank,
we can afford disk-space, network bandwidth, RAM and CPU cycles. What we can't
do is manage our internals systems very well (ooops, well, not _this_ bank you
understand, but others I've worked for before ;^))

A similar perl-advocacy issue that rarely gets mentioned is the fact that the
language includes it's own documentation. Losing documentation to various
internal and external components / libraries causes us a lot of grief - the fact
that perldoc is intimately part of perl scores us a lot of points.

Cheers

Tim




_________________________________________________________________________
                                                                      
The information contained in this message is intended for the addressee
only and may contain confidential and/or privileged information.
If you are not the addressee, please delete this message and notify the
sender; you should not copy or distribute this message or disclose its
contents to anyone.
Any views or opinions expressed in this message are those of the author
and do not necessarily represent those of WestLB or any of its affiliates.
No reliance may be placed on this message without written confirmation
from an authorised representative of its contents.

Reply via email to