Backcompat is holding us back!
I always cringe when I hear this battle cry. Isn’t that sentiment exactly what set the trajectory for the Perl 6 effort? Maybe it’s just been so long that people have forgotten.
But that is precisely how Perl 6 became such an amazingly long trek: once you remove the constraint of staying compatible, everything is suddenly, potentially, up for reconsideration. Then when you start changing things, you discover that changes in one part of the language also affect several other, remote parts of the language. So it starts with the simple desire to fix a handful of obvious problems in obvious ways… and spirals out as you make changes, and further still as you make changes in response to your changes, ever further and further.
At that point, it is exceedingly likely that the project will fizzle out before it ever comes to any fruition. But even if you have the perseverance, you face an uphill battle: unless your project has the community’s implicit blessing as the successor (as Perl 6 does, due to Larry’s presence), it is likely to simply slip into oblivion… the way Kurila did.
So yes: backcompat is holding us back… the same way that gravity is. It keeps us from floating away untethered.
Note that I’m not saying it doesn’t really hold us back. I’d love to travel to space easily, too! I still await Perl 6, as well.
But what I think, every time someone proposes to throw off the shackles of backcompat and go for it, is that we already have one Perl 6 – we don’t need another.
Waxing philosophical
Thanks for putting into words what irked me when Moe decided to not even try to maintain any CPAN compatibility.
"Lets not even try, cause last time we did, it didn't work" is pretty horrible advice, and completely misses the idea of "learning from your (and others) mistakes".
Did I say it didn’t work last time we tried? :-)
(Oh. Yeah, OK, I admit I did say that about Kurila.)
I try to distinguish between features that are actively harmful (pseudohashes), features that are harmless when avoided (dative syntax), and features that actively prevent future improvements (XS).
Breaking XS would be awful, but it's probably necessary for the kinds of internal changes that produce either dramatic speed gains or allow further experiments on the CPAN. Unfortunately, it breaks most of the CPAN.
Changing the method invocation operator from an arrow to a dot doesn't fall into that category.
Actually the XS problem is easily fixed (for some definition of easy). Stop exposing the Perl guts via a macro layer and provide a real API (aka - level of indirection). Of course, then you need to convert all XS modules over to use it, but with a sensible deprecation cycle (of like 2+ years) that should be do-able (not to mention that it will shake out all the old crusty XS modules that no one maintains or cares about).