On Sat, 20 Mar 2004, Joseph Alotta wrote: > I'm not a major hacker type, like you guys, but nobody mentioned the > bytecode strategy. Maybe that will work in your case.
Andrew explained it better than I can, but that basically isn't an option with Perl5. When you run a Perl script, the perl program (/usr/bin/perl, perl.exe, etc) reads in the text, parses it down to executable code, and runs it all at once. Because this is all so tightly intertwined, making a "bytecode" compiler for Perl is basically the same problem as making a "binary" compiler for the language: you'd have to untangle the current execution cycle in a pretty deep way, but in the you're not likely to save much time beyond that which is required to launch /usr/bin/perl or perl.exe itself. On the other hand, what you're suggesting seems to be one of the design goals for Perl6 / Parrot some day, and you can do this today with Python, because the Python execution cycle involves caching your .py script's bytecode as an executable .pyc file, which can be reused later. But then, one of the objectives here was obfuscation, and again, as Andrew described, obfuscating an interpreted scripting language (Perl, Python, Java, etc) is basically an exercise in futility: there are always ways to get back a functional description of what a program in Perl (or the other related dynamic languages, I assume) is doing. Sherm's right: Perl just isn't the right language for that problem. If you're hell-bent on doing it in Perl, the best way I can think of is to make a black-box by having your Perl script run on a locked down machine you control, and have a client on the customer's computer push your data to the black box & deliver the results back to the customer afterwards. But that's just silly for many (most?) problems... -- Chris Devers
