Slashdot Mirror
Perl Is Undead
Ptolemarch writes At the Yet Another Perl Conference beginning today in Orlando, the first keynote squarely blamed Slashdot for starting the "Perl is Dead" meme in 2005. Let's be clear: if Perl was ever dead, it must now be undead. If you can't be at YAPC, you can still watch it live.
Shall we drag out all the other obfuscated code contests and judge all languages guilty by the most heinous crimes committed with them? Remember that C and C++ give us Windows.
More telling is how utterly fast Perl is compared to the other languages. I've run most of the sample files from this language shootout and had remarkably similar results to what they list there.
The Perl version performed on par with the C and C versions, and it's growth/memory usage stayed pretty consistent throughout. The other languages were horrid. They took much longer, and their memory usage grew significantly during the run.
I use Perl still when doing scripting tasks. I love Perl, always have. I don't, however, necessarily think it's the right choice for building a medium to large web-based application any more. Sure the performance is there, and there are some great frameworks like Catalyst and Dancer, but to me, they still feel a bit antiquated to some of the other technologies I've used. Plus installing tons of CPAN modules can get a little trying at times.
Writing a virtual machine in C is dead-simple. It's just a loop over a table of opcodes. You can even get fancy and thread your dispatcher (that is, replace your loop conditionals with direct jumps to the next instruction handler), making it nearly as fast as JIT'd code because the CPU can pipeline all your virtual instructions.
In fact, writing a virtual machine is arguably easier than writing an AST (abstract syntax tree) interpreter (which is what Perl5 is), because it's an elegant abstraction that cleanly separates areas of concern.
If you can't write a VM in C than you're definitely not an experienced programmer. And if you think using LLVM to write an interpreter is easier, than you're just... I don't even know what... totally out of touch and have no clue how this stuff works.
The VM isn't the problem. It's all the bells and whistles. The typing and object system. The FFI system. Garbage collection. Perl6 is a complex language, and they tried to bury too much of that complexity at the virtual machine layer. Or at least, they got tangled up in it.
They couldn't use existing interpreters because at a minimum they wanted sane string prototype with a proper understanding of Unicode, something Java, C# and other systems lack. Perl 6's NFG (normalization form G) is a thing of beauty, but to make it fast you have to put it at a low-level. As for why they got hung up on all the other stuff, I don't know.
To see what a fast, practical, feature-rich, and state-of-the-art (non-experimental) virtual machine looks like, I would recommend Lua's VM. It's about as simple as you can get and yet remain widely useful. It's completely written in portable, ANSI C (1989), it's several times faster than Perl, Python, Ruby and most other non-JITd interpreters, and the bytecode dispatcher is basically a giant switch statement inside a loop--very easy to read and work backwards through how the typing system works. (It could be made even faster by threading the dispatcher, but to remain concise and performant--without a mess of function pointers-- would require using a non-portable construct like computed gotos. Although the only C compiler I know of which doesn't actually support computed gotos is Visual Studio.)