* On Wed, Nov 18 2009, Aristotle Pagaltzis wrote: > * David Golden <xda...@gmail.com> [2009-11-18 16:05]: >> So creating/destroying Perl objects -- even just for things >> like argument passing on the stack -- is part of the cost of >> the flexibility of Perl. When that becomes a bottleneck in >> a tight loop, that's when XS becomes a potential option. >> >> That's not a knock on Perl -- that's just part of the design. > > It isn’t inherent in the language design. A tracing JIT runtime > *could* make Perl go faster than compiled code.
So untrue. Python has this "problem", but people wrote new implementations anyway. Psycho, PyPy, and Unladen Swallow may not run every program ever written, but the programs they do run run much faster. If someone were to write a new VM, legacy code could run on the old VM, and new code can be tested and tweaked to run on the new VM. If you don't want to use the new VM, then don't. Get that 1000x speedup some other day... The real reason for the lack of another Perl VM is that Perl programmers are very, very lazy. ;) -- print just => another => perl => hacker => if $,=$"