Perl 5 is still in business but lost lot of its market share since the announcement of Perl 6. I'll outline the technological problems with perl5 which led to perl6, the management problems, and my various attempts to get perl5 into proper shape. parrot, the perl compiler, p2 and cperl. There are interesting observations in toxic cultures and technological problems.
Session type: 40-minute presentation Topics: The new stuff Abstract
Perl 5 is still in business but lost lot of its market share since the announcement of Perl 6 in 2002.
I’ll outline the technological problems with perl5 which led to perl6, the management problems in the p5p perl community which led to serious brain drain, the various attempts to get parrot and perl6 into shape for the last 14 years and more. There are a lot of technical and management comparisons to be made between the state of parrot and perl5.
I am the current parrot maintainer which is not used as perl6 backend anymore, because many problems severely damaged its usefulness and performance in a few years under weak non-technical leadership. When they burned out, I took over the project and started undoing all the damage done in the optimizer, garbage collector, data structures, but not yet the jit and the runloop, so I got it only 20% faster, not 200%. But it is still a worthwhile project and the damage can still be undone. perl5 can learn a bit from the parrot decline, because they are also sailing under non-technical leadership since several years also and their problems are very similar.
Then I’ll cover my various successful attempts to improve the perl5 vm performance.
First with the perl compiler which is used successfully in production by cPanel for over 10 years. Using much less memory, startup time and destruction time. With the 3 stages, the original compiler for 5.6, the current version based on 5.14 and the new version based on 5.22 and eventually our own version cperl. This will cover mostly static data structures in a dynamic world. Then the reborn attempts to study fast interpreters for dynamic languages post-parrot, inspired by v8, strongtalk and lua. I am the maintainer of potion, _why the lucky stiff’s abandoned rewrite of a fast and small core ruby interpreter, and decided to base my perl5 rewrite (p2) on that 2 years ago. In parallel Francois Perrad also took a lua-based vm to write a nqp backend for perl6, tvmjit. There can be lot of good things to say how to write fast interpreters. And the new rperl is an rpython alike attempt of a fast restricted subset of perl5, mapping data and code to C++ classes, compiled natively on the fly. And in the end I’ll cover my fallback to fork perl5 to cperl, to be able to start again in 2002 and undo all the damage the current maintainers had done in the last decades. Most of the new perl5 features are a desaster and I needed to start over. Currently cperl is fully perl5 compatible, but only 1.5x faster than perl5. perl6 already outlined the features and syntax extensions to follow, which just have to be implemented into perl5 proper, without riscing breakage. We call this new subset perl 11 (5+6=11) and it was founded in Austin 3 years ago. There are several exciting features being worked on, which makes cperl 2-3x faster and close up to PHP7, which is a fantastic effort btw. cperl is already faster, uses less memory and has technical competent leadership and will have better compiler support, optional static typing, faster arithmetic, proper signatures, function inlining, loop optimizations, native arrays, a fast object system (10x faster and smaller than Moose, i.e. perl6 roles) and a builtin FFI. Even if the perl5 maintainers added a code of conduct recently, it’s still a toxic culture similar to other languages sharktanks, but don’t despair. You don’t need them. perl5 is entirely CPAN, the libraries and outside maintainers, and you have alternatives. python is technically much worse and they still have won over perl5.