Rafael Garcia-Suarez's The Future of Perl 5 is worth your time to read. If you think I'm crazy, you might find him sane. If you think I'm sane, you should consider his arguments seriously. (I think Hegel refuted himself, but he may have had a point.)
Rafael is completely right on some points:
The big advantages of outsourcing syntax experiments to CPAN is that the community can run many experiments in parallel, and have those experiments reach a larger public (because installing a CPAN module is easier than compiling a new perl); that enables also to prune more quickly the failed approaches. This is a way to optimize and dynamize innovation.
The cost of the average Perl programmer experimenting with a new form of syntax is low. There's little risk to push that code to production servers. (It happens, though; my company had Ingy and Schwern on one project back in the Spiffy days.) Of course, this keeps feedback low, but the risk of backwards-incompatible changes for experimental code is minimal.
Given sufficient experimentation and testing, it's possible to revise and refine these experiments into something more stable and workable which addresses the necessary uses effectively. That doesn't happen enough, but I believe the CPAN ecosystem can and should encourage it. See also Schwern's perl5i.
I believe Rafael is absolutely wrong to write, however:
a patch to add a form of subroutine parameter declaration, or to add some syntactic sugar for declaring classes, are probably not going to be included in Perl 5 today. Those would extend the syntax, but not help extensibility -- actually they would hinder it, imposing and freezing a single core way to do things. And saying that there is only one way to do it is a bit unperlish. It's basically for the same reason that we don't add an XML parser or a template preprocessor in the core: no single, one-size-fits-all solution has emerged.
It's true that there's plenty of debate over advanced forms of subroutine signatures -- slurpy arguments, named versus positional arguments, default values, et cetera, but when most existing Perl subroutines look something like:
sub foo
{
my ($bar, $baz, $quux) = @_;
...
}... it seems silly to suggest that supporting something as simple as:
sub foo ($bar, $baz, $quux)
{
...
}... won't be common to every potential serious signature declaration form.
Likewise can you imagine a class declared in Perl 5 that didn't immediately start something like:
class Foo
{
...
}Given that Perl 6 has already blazed a (stable) trail through these syntactic weeds, and given that a goal of modern Perl 5 is to provide a smooth transition path between Perl 5 and Perl 6, I have trouble imagining the kind of seismic shift necessary to render this syntax unsupportable.
Perhaps there's no single syntax that provides every potential feature necessary -- but a default that works effectively for 90% of code and offers an improvement for 98% of existing programs seems like a useful use of time.
A stronger argument is that the steadfast refusal of the core to provide anything other than the roll-your-own-object-system tinkertoys first conceived in 1994 is responsible for the explosion of modules in Class::* on the CPAN in the past several years -- and that's only from the top 2% of Perl programmers worldwide with the stubbornness, will, and permission to make their improvements over stubborn and parsimonious defaults available to the world at large.
I suspect that if the defaults were really as good as some people might like us to believe, the Class::* namespace wouldn't be so crowded.
I don't want to misrepresent Rafael's arguments. He's a thoughtful man and a good programmer; he can represent his own arguments. You should read them. You should think about them. He may be right.
However:
But large-scale experimentation on CPAN enabled the community to make Moose much better than whatever a handful of P5Pers could have designed by themselves.
... what prevents the Perl community from doing the same and improving core syntax? Certainly that's how Perl 6 works. Certainly that seems what pumpkings would like to see -- motivated volunteers doing some work, getting some feedback, and refining new ideas and enhancements to existing ideas.
Perhaps I don't understand why a modest improvement (such as parent over base, with the corresponding subtleties that many people will just ignore) is okay in the core in a module but a modest improvement that could clarify and simplify and shrink almost every existing program is not.
... unless the fragmentation in Class::* is somehow a good thing.
