I don't understand you Shlomi. By now you should know that any comparison between Perl and Python just leads to some Python fan pulling out the "Perl is not readable" meme. It is totally worthless to talk in public about this. There is always the bad apple to ruin any normal discussion.
Nevertheless let me comment on some of your points, On Mon, Jul 13, 2009 at 11:10 AM, Shlomi Fish<[email protected]> wrote: > > 1. Syntax as an Indicative of What the Language is Doing: > --------------------------------------------------------- > > He said he didn't like Perl syntax like "push @$array_ref, $val;" because > of the sigils. I said I happen to like it because the extra characters > convey meaning. By looking at this code I know that $array_ref is an array > reference, that it is being treated as an array and that one appends a > single ("scalar") value to it. On the other if I see code like this: I like the sigils ($ @ %) indicating the data type but I dislike that in Perl 5 we need to dereference arrays writing @$aray_ref and there even more horrid constructs. Luckily in Perl 6 it is cleaned up hence I prefer it over Perl 5. Some people still add & in front of the function names even though that requirement was eliminated 15 years ago. > > 4. Hiding Code By Using .pyc's > ------------------------------ > > The python backend compiles the text-based Python code to bytecode, and > caches the result in .pyc files. My partner to the conversation argued that > he often uses these .pyc files to "hide" the source code from people he's > distributing it to them, so they will be unable to reverse engineer it. > > I told him that with a symbolic language such as Python, such .pyc files > do not provide adequate "protection" as they contain the names of identifiers > and other detailed information on the code. Let's go to the car analogy. Locking your car does not stop someone from steeling it but it makes it more difficult. It might also be the difference between making you eligible or not to receive payment from the insurance company. <story> Actually I have a personal experience with this. A long time ago I had a car that cost only a few thousand shekels so I did not make the comprehensive insurance. Unfortunately I have not installed Rav-bariach-lock either. One night some kids stole it, used it for a few weeks and crashed it. The police found it and I had to handle the disposal of what remand from the car. It clearly wasn't a professional car stealer - did not take it for the 'monetary value' of the car but for the fun value. They were script kids. If the car had a lock on it they would have moved to the next - easier - target. </story> Creating byte-code might not stop those who really want to steal your code but it will make it slightly more difficult and it might make the difference for the legal department. Talking about obfuscation and Perl on a Python list is just plain silly as you could see from the other comment. For some reason Python programmers - especially those who once used Perl - cannot stop themselves from such stupid derogative comments. Technically you might be right that obfuscation and bytecode pose the same level of difficulty for reverse engineering. I don't know. What I know is that obfuscation is not an accepted practice in the industry and compilation to byte-code is (see Java, C#). So the fact that Perl 5 cannot be compiled to bytecode is a major drawback in every place where a company wants to distribute its code to customers. Luckily this is too solved by Perl 6 so if you write in Perl 6 you can already compile it to Parrot byte-code. regards Gabor -- Gabor Szabo http://szabgab.com/blog.html Test Automation Tips http://szabgab.com/test_automation_tips.html Perl 6 Tricks and Treats http://szabgab.com/perl6_tricks_and_treats.html _______________________________________________ Perl mailing list [email protected] http://mail.perl.org.il/mailman/listinfo/perl
