volks,
Technically there is a list of reasons why you would
want to, as professionals, code in a language that more
fully provides for the delivery of
byte-code-only
binary-only
releases to the customer. Since if you have read the
gory details about perlcc you know that it is really
an unsupported feature to try and deliver perl in anything
other than the classic open source model. Remember Kampfrs,
if they can read an ascii file, they can read you Perl Code.
So if all you are doing is 'code re-use' - then perl is fine
enough for all of that, but if you find any of the following:
a) the defense of any intellectual patent rights
b) the ONLY defense of any 'trade secrets'
c) it shows your flexibility to interoperate with complex
build and release systems. Allowing for ant v. make
v. nmake v. jam build racing competitions. { good
secondary revenue stream if you are managing the
compensation for probability funds - since of course
betting is illegal in many areas - its best to structure
this as a hedge fund... }
d) vendor supplied, vendor supported - and you can keep
management on the fone with your customers and the vendors
trying to establish that the bug is not in your software but in
the underlying technology while you work on the next release.
e) the really important one:
Obliges your management to spend time with patent attorneys
rather than making squeeky toy noises in the engineering
department as they try to reboot their Etch-a-Sketch, because
IT will not trust them with a real laptop.
then clearly you should not try these tricks with Perl - and
should support more traditional solutions.
ciao
drieux
---
honest - I'm trying to follow timothy johnson's
advice that the Looney::Tunes Modules is depricated
but, well I'ts just not un-installing properly.
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
