in reply to RFC -- Evolving Perl: a Decision Theory Approach to the Challenges of Perl 7

The major problems I see are that Perl historically has been a different language with each major revision, although perhaps Perl 6 was too much of a difference.

Could a more conservative approach to Perl 7 be useful, perhaps limiting the breaking changes to making use strict default when parsing from a file (meaning, except for perl -e ... one-liners), making use warnings default in all cases, enabling all non-experimental features from the end of Perl 5 by default, and dropping the Perl 5 experimental features that were not promoted to core?

XS will be "fun" no matter what we do; there are already compatibility shims for XS/perl within the 5.x series. While I think that the burden of introducing "XS2" would be excessively high, it might just be workable if XS2 extensions can still be compiled into XS and used with perl 5 and XS2 gives significant benefits with Perl 7.

The key here is not breaking backwards compatibility without a very good reason and "PBP says that is bad" is not a good reason.

Replies are listed 'Best First'.
Re^2: RFC -- Evolving Perl: a Decision Theory Approach to the Challenges of Perl 7
by Anonymous Monk on Dec 28, 2020 at 09:18 UTC
    Examples of good reasons for breaking backward compatibility, are removing '.' from the module search path, and making hash functions output different results from run to run. 'use v7' is as little boilerplate as possible, in my view. Core implementors have come on to say that breakage such as new strict / warnings default are not needed for continued improvements to core.