Writing perl^W^WEfficiently writing in perl in fact is so effective that I(/you) will take the speed issue for granted when most of what you write is for one-time use or for use that doesn't require the speed. I write perl and C and Java everyday and curse at C and Java quite a lot for not allowing me to write «my $c = 1;» instead of «int c = 1;» or «private static long c = 1;» or whatever it takes for a local/lexical variable to get in scope.

I find myself write less and less C as I can do almost anything in perl, and write it over ten times as fast in code that is easier to maintain. Some projects however still need perl: the code cannot be shared by law and perl has no good code-hiding feature.

Defining a useful data model in C might be quite a challenge. The autovivication in perl is a joy compared to how to deal with data in C and - even worse - in Java.

Compared to C and Java, changing data-structures, return types etc is so much easier.

I never wrote anything in python. I however read a lot of python scripts, mainly to fix bugs. I've read enough not to like it. Ruby on the other hand really looked as a good alternative when I would require a good OO scripting language. Python has - in the past - quite often said that they do not suffer from version incompatibilities, but to be honest, that is completely untrue: they suffer just as bad as any other (scripting) language. Most reasons for digging in python where just because of that.

I find myself write less and less C as I can do almost anything in perl, and write it over ten times as fast in code that is easier to maintain. Some projects however still need perl: the code cannot be shared by law and perl has no good code-hiding feature.

I think that we are on the same page here.
I am not so sure about the lack of a "code-hiding" feature.

I use the Active-State Compiler and this thing is pretty hard to "decode". Many years ago, a massive power failure took out my Power Supply and 3 HD's. That trashed my Perl source code for one project, but not my .exe. The .exe code still runs over 5 years with no reported defects - so I am happy about that! If somebody can help me recover the source code, I would appreciate it. But I am skeptical. It is not as easy as one might think.

I love Perl. A wonderful language.

A new school quarter started Monday and I'm going to be working with an assembly class. I like it. Perl can kick butt vs this stuff except in very high performance situations.

I assume you are referring to PerlApp by AS. Use a C debugger, set a breakpoint in eval_pv() or something similar (I dont remember anymore) (finding eval_pv in the process will be the painful part), once the AS decompresser/obfuscator decrypts it into memory, it will be passed as 1 big string to the perl5**.dll which will be in a temp dir somewhere on disk.

The other choice is to RE the PerlApp obfuscator algorithm Re: Security, is it to much to ask?. Its been published a couple times in history, for example A real challenge and Decompile PerlApp but AS changes it constantly for obvious reasons.

Well ... the speed ... it's both right and wrong. If you translate some code statement-for-statement from C to Perl, then Perl will lose hands down. For a large group of tasks a well written Perl script will beat anything you could write in C in reasonable time to pulp. The built-ins of Perl had been hand-optimized for years so if you can implement the task by a few calls to those built-ins, your program will finish sooner than if you attempt to reimplement them in your own code. In most cases it simply doesn't matter though.