[Discuss] Interpreters vs Compilers

[Peter Scott]

>This is why I'm not so much of a fan of "speed" benchmarks which are 
>usually fairly artificial.  It could just be that Larry Wall (Perl) 
>and Guido van Rossum (Python) are poor coders.
>
>Now if that last statement doesn't start a flame war, nothing will. :p

Harrumph.  The most important speed benchmark IMHO is how quickly you 
can get the code working.  That aside, the Perl builtins are coded in 
hand-optimized C, so they will often work faster than a naive C 
implementation.  The speed loss is in the transitions between complex opcodes.

>I must pluck up courage and have another go at learning Perl.  I have 
>in the past read several chapters of a Perl book but found the 
>language very arcane and one that delights in obfuscation.

Sounds like you're reading the wrong books :-)

The language doesn't delight in obfuscation, some programmers 
do.  There's an obfuscated C contest but people don't accuse C of being 
obfuscated.  Just because Perl is featured enough to make golfing games 
[http://perlgolf.sourceforge.net/] fun doesn't mean that behaviour 
should be sanctioned in maintainable code any more than creative abuse 
of the C preprocessor [cf: Code Complete, Writing Solid Code].  There 
are languages that don't lend themselves well to obfuscation, like SQL 
and COBOL, but how much fun are they?  (Yes, I know about the COBOL 
Goldilocks program, we got a printout of it in college.)  Then there 
are languages like JCL that are obfuscated to begin with and were never fun :-)

-- 
Peter Scott
Pacific Systems Design Technologies
http://www.perldebugged.com/
http://www.perlmedic.com/