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.
Meanwhile, Perl 5 being phased out of system building / admin tools and web frameworks. Even Perl 5 is dying.
Not for me, I write new Perl 5 code all the time. Get some real useful work done with it too.
Perl 5.20 was just released and "represents approximately 12 months of development since Perl 5.18.0 and contains approximately 470,000 lines of changes across 2,900 files from 124 authors."
That doesn't seem to bad to me, but I'm not sure how that number of core release authors compares to other languages like Python or Ruby.
Is it dead? Well, some quick scripting can tell us the truth, using Bash and of course Perl.
On my Ubuntu notebook and main machine:
sudo find /etc /bin /sbin /usr/bin /usr/sbin -type f -executable -exec file -b "{}" \; \ /script/; /(shell|python|ruby|perl|bash)/i ) {
| perl -MData::Dumper -nle '
next unless
if (
$types{$1}++
}
else {
warn "Other: $_\n"
};
END {
print Dumper(\%types);
}'
Output:
Other: a /usr/bin/make -f script, ASCII text executable
Other: a nickle script, UTF-8 Unicode text executable
Other: awk script, ASCII text executable
$VAR1 = {
'perl' => 283,
'python' => 104,
'bash' => 1,
'Ruby' => 3,
'ruby' => 9,
'shell' => 602
};
On a server:
Other: a /bin/dash script, ASCII text executable
$VAR1 = {
'Python' => 36,
'Perl' => 139,
'shell' => 267
};
Looks very much alive. Unless of course, Perl realized what it was calculating and cheated and made it's own numbers up on the fly...
Comment removed based on user account deletion
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.)