On Fri, Oct 17, 2003 at 06:43:03PM -0400, Mr. Lindsay Morris wrote: > You know why Java is more widely used (by sw development firms) than Perl? > (Even though it ... well ... I don't like it...) > Because you can send your customers compiled code.
Google for "Java decompiler". :-) While I do agree that a cross-platform bytecode is a neat thing to have, it does not prevent anybody from reading your source code. > Maybe Perl 6 offers some help here, too - not sure. Perl6/Parrot does have such a bytecode-compiling facility now. In fact, Perl 5.8.1 also has a decent platform-specific bytecode module, so if you are shipping pp-packed executables anyway, that may be good enough. And yes, I agree that a B::Bytecode input filter for PAR/pp may be very useful for some people. I have already mentioned it in pp's documentation, that "a ByteLoader variant of pp is entirely possible". > I believe that developers need this kind of control if Perl > is to become usable for commercial quality code. Well, "more widely usable" maybe, but Perl is hardly non-usable today in the business world. Bricolage, Webmin and RT are all good examples of "commercial-quality" perl systems. > (Maybe that's anathema to the open-source community. > I'm not trying to be flame-bait here, but encryption > would sure help us a LOT.) I think it will also help us, if we can make a distinction between "source hiding" (or "source obfuscation") and "source encryption". The term "source encryption" is ambiguous: it may also mean cryptographical encryption, where the user has to enter a passphrase to run or see the data; it may also simply mean "converting plain text into code". Since it is not always easy to tell which meaning is intended, I'd be grateful if we can use "source hiding" on PAR-related discussions. Thanks, /Autrijus/
pgp00000.pgp
Description: PGP signature
