in reply to
Perl 6: Managing breakages across Rakudo Star versions
Let me be frank: please stop calling this thing “Perl 6.” Call it Rakudo ... present it as a new language. (With a sexy trendy name. Do the whole faux-Ninja thing, to appeal to the twenty-three year olds among us who still love spending all day and all night hacking software.) ;-) This is IMHO a much better positioning of this project at this point in time, and not a criticism of the effort or its extreme lateness. In support of this notion, I offer these points three:
If it’s source-code compatible with Perl, it’s not better, and it is now at cross-purposes with itself. The internal complexity of the system shoots up, and stability goes down. Various other projects, including ADD 1 TO COBOL GIVING COBOL., have encountered this issue before. You really can’t change an existing language that much and call it the same language.
If it’s not source-code compatible, then “it is a different language,” and everything of significance is going to have to be ported, so the CPAN library effectively splits. Very well, then: let it split, and do it cleanly.
There is a mammoth installed-base of Perl5. These installations consist not only of the interpreter executable, but also the CPAN libraries. The possibly major changes to these libraries which might be attempted in order to accommodate Rakudo might well de-stabilize them, causing significant business problems for installations which have no interest in adopting Rakudo at this time.
If Rakduo, called Rakudo, is deployed in a parallel but separate track, the cost/benefit analysis holds up. If, instead, it disrupts existing installations in any way, it produces cost without benefit. Perl has a history now. It has a legacy to support.
Once again, this is not a flame; this is a Meditation. I invite equally cordial comments; not just +/- votes. What do you think in response to my comment, and why or why not?