YAPC got me thinking about Parrot and Perl 6.
Perl programmers are excited about a few things... bioinfomatics (still, but mostly voyeuristicly), games (because we're programmers, and most programmers start out programming for fun and only continue programming out of love, and games appeal to this side of us), MVC frameworks (because they made Ruby marketable, and we hold hope that they'll make our beloved language marketable too), and Perl 6.
We're also excited about Ruby, which has a great minimal aesthetic, embodying in its own design and implementation and various core modules the ideal of doing the simplest thing possible. A lot of us Perl people are tired of feeling like we're crumbling under our own weight, with our bloated and crufty Perl 5 core, overly fat CGI.pm, and, worst of all, that bloated, diseased application we're maintaining for /$work/. And, oh baby, we've wanted named parameters for so long, we can't even tell you...
Bugging poor chromatic in his blog got me thinking and I thought I'd spooge around in here rather than there.
Anyway, we're excited about Parrot because of the features we were promised -- it would be fast, and it'll run a bunch of languages. The Inline:: modules for Perl 5 let us run a bunch of languages, but doing so in one virtual machine will magically unite the world and make us all brothers. As all-embracers, we like that.
But we do not want to work on Parrot. Some of us even tried a bit before realizing as much, as I did. Someone came and told me that it was Perl's future (Dan) and I guess I really wasn't sure then. The time passed cemented my early doubts.
* There are already a lot of VMs; building another one will accomplish nothing; it'll further spread efforts and fragment standards rather than unite anything.
* Complexity is in the wrong places; it started small and lean but it did so at the expense of pushing important infrastructure higher up, to be implemented on top of the whole stack, hence the top-heaviness mentioned in the title.
* Even though important complexity was pushed up, the core still got bloated with a bunch of premature optimization. There's a cartesian explosion of accessor methods as programmers tried to manually unroll all of the permutations of what two types might be operated against each other *multipled* *by* how they're being accessed (array element, scalar, hash element, etc).
It's bad form to criticize efforts while not doing anything -- I know. But here goes. Here's what I would like to have seen people do for me while I sit on my fat ass and watch (or at least wait).
* Bolt named parameters onto Perl 5 -- would have taken a fraction of the effort of all this other stuff.
* Bolt switch onto Perl 5 -- oh, wait, I'm getting this in 5.10. w00t!
* Bolt a clean 'has' style instance data syntax onto Perl 5 OO -- would have taken a fraction of the time yadda yadda.
* Perl 6/Parrot already breaks XS (unless you embed an old Perl 5, of course) so why not do exactly that in Perl 5 in the name of being able to clean up and deprecate a bunch of nasty stuff from Perl 5 core -- just in case, you know, it takes a while to get Perl 6 ported to all of those platforms Perl 5 runs on and for people to make the switch. It would be silly having Perl 5.12 embed a Perl 5.10 just so that old-style XS modules work but it would be about the same boat Parrot would be in but a lot quicker, and the door to extensive refactoring would be open. Hey, we got all of these awesome tests for Perl 5 now, why not?
* Make Perl 5 self-hosting. Get it generating x86 assembly (including linking to a libperl.a). Marc Lehmann's Perl 5 JIT (Faster) is a start. There's a pure Perl implementation of the optimize phase. So the parser/lexer would have to be rewritten in Perl 5, and then the ops/run_ops interpreter (though in practice the one in libperl.a, written in C, would probably be the one actually being used). Then, hey, Perl 5 would be faster! With some static analysis (done in Perl, care of B) most of those pesky if() checks done at run-time could be optimized away, and moving towards a pure vtable implementation (breaking XS, remember) would get rid of a whole lot more. And then with the grammar/parser being written in Perl, it would be easy to make it swappable and add a Perl 6 front end.
I guess I'm feeling pretty staunch in thinking the refactor/adapt route is the smart route, and the rewrite from scratch just lets us make too many mistakes that, through luck and an amazing collection of smart people, the Perl core community had previous been able to dodge.
Long before the Netscape 5 thing (see jwz's essay), I watched LPMuds, one after another, decide to rewrite their libs to get away from the old style 2.4.5 way of doing things, and add more wizard security (completely useless in a MUD, from the player's point of view) and some ambitious, easy to sell, whiz-bang features. One by one, they undertook these ambitious projects which, with exceptions counting one in hundreds, outlived the attention span of the players and developers both, and spelled death and doom for the game.
I do not want to see this fate befall the Perl community.
Perhaps I would get off my lazy, fat ass and refactor and break Perl 5 if there was any indication that other people felt this way, but as it is, it seems like everyone is on the same death march.
Yes, _Perl 6 Now: The Core Ideas Illustrated with Perl 5_ stemmed out of these feelings of apprehension.
-scott
Personally, I'm just sticking with Five. I don't see any reason to learn the new language, Six, as of yet. It can succeed or fail, and it won't change Five. The Perl community != The Six community.
