Re: Obscuring code?

From: <[email protected]>
> Actually, this was suggested and discussed with management.
> The response you suggest is definitely not the take I've received from
> the environments I've been in as a professional web developer over the
> last several years.  Protecting the company and the client will (or at
> least should never) be viewed unfavorably by management.
>
> Keep in mind, I mean hiding it from poeple outside of the
> company (not including the client).  Of course you want others (you
> trust) to examine the code.

Source obfuscation still remains a major (managerial) reason for
Java development for exactly that reason.  (reverse-engineering
lessons > /dev/null.  I gave them.)

> In the end, it's up to the end user on how they use the tools.
> Taking the tools away in fear that they might be misused is a bit
> big-brother-ish, which seems more against the nature and philosophy of
> Perl than some of the smaller examples I've read in this thread so
> far.

Which is why I find it... unusual, I guess... that the Perl community seems
to be so passionate about preventing it in any form.  (Filter::
notwithstanding.)
I understand the benefits of the current mechanism, but I fail to see how
the
active omission of any such capability, simply because I|you|we|they don't
believe in the validity of the arguments fits into the same conceptual
ideology
that I|you|we|they are trying to protect in the first place.  It's not
biological warfare.
If someone *really* wants to hide their source code, Perl should help them.
(Just like Perl should help them delete their system disk, if they *really*
want
to.)  So what if their reasoning is irrational or erroneous?  Source
obfuscation
itself may reflect poorly on the company, but the ability to do it may
reflect
favorably on Perl.  Phil has an excellent point above.