At YAPC::NA 2009, Chip and sungo announced the corehackers project.
I believe this project is important to the future of Perl 5. It has several parts:
- To encourage new developers to work on the Perl 5 core (internals, ecosystem, and libraries).
- To improve documentation and processes to make improvements to the Perl 5 core.
- To experiment with new features and design decisions.
- To clean up the internals.
- To mentor new and recurring contributors.
- To take some of the burden off of the overworked, underappreciated pumpkings.
I see corehackers as the other side of the important perl5i project; important features perl5i identifies and stabilizes can come into the corehackers tree (or forest, I suppose) for further experimentation without destabilizing the main development trees for Perl 5.
This is a huge benefit of Perl 5's switch to Git last year, and I'm glad to see Perl 5 development take advantage of it.
One of the obvious inspirations is the Linux Kernel Janitors project, which has performed similar functions for the Linux kernel.
The project is in its early stages. You can fork Chip's own bleadperl repository on GitHub and experiment with making changes. The IRC channel is active (if a little bit scattered; it's not clear exactly what's happening when, so you have a chance to guide it to your desires and expectations), and there are plenty of people interested in experimenting with all sorts of pent-up ideas.
In particular, I'm most interested in cleaning up some of the internals to make them more readable, more optimizable, and more amenable to further extensions and enhancements such as compiling Perl 5 to LLVM. A 30% performance improvement is likely, with few changes.
I've personally forked an experimental Perl which enables strict unilaterally, unless running with the -e flag, without having to use any module. I'll write more about that soon.
I fail to see the value in a perl that will fail to compile a lot of core modules. I'm not even starting to mentioning CPAN. (But some of my modules for example will break.)
Maybe that will teach you that breaking backwards compatibility is stupid, though.
"Cleaning up internals" is huge. Too few people are willing and able to work on perl's innards. My particular chafe point is all of those bloody macros. The interface to the SV, AV, HV, etc structures is complex, layered, large, and idioms for accessing them get repeated all over. This attitude is often a naive one, but I feel that if I'm going to be bothered to learn my way around this stuff, I might as well clean it up while I'm in there. I'm sure as I learn more about it, my attitude will change.
-scott