Depends on the code: Some of it won't compile without providing just the right set of flags.
In case of C, for me the crucial feature is not so much full backwards compatibility, but interoperability (you can link the object code regardless of the language version) and the convenience of using the same frontend executable.
In case of Perl, the former is currently possible to some degree via the Perl5 module Inline::Perl6 and the Perl6 module Inline::Perl5.
Personally, I would like to see the latter become a reality as well - this is the solution I'd perfer over trying to distance Perl6 from Perl5 via rebranding.
I may be imagining things but, peering years into the future, it seems this versioning management aspect of the P6 toolchain might end up being the foundation of a new multiple lang/compiler/module version juggling Perl package manager that can be used with P5, P6, python etc. Does that make sense to you?
One of the things I've heard is that `print` went from a keyword to a subroutine in Python, or something to that effect. In Perl 5 for most of them there is not really a difference, and what difference there is gets smaller every year.
Another is Unicode, which Perl 5 managed to improve without breaking most existing code. (some of it has to be enabled with a pragma statement)
Usually the only code that gets broken, is code that digs into the internals in some fashion, or use an unintended “feature”. (or occasionally even a feature that should have never been added in the first place)
One such unintended feature which relied on the compiler generating incorrect code was:
sub foo {
my $bar = 10 if 0;
say $bar++;
}
foo; # 10
foo; # 11
foo; # 12
Which was superseded by the `state` declaration. sub foo {
state $bar = 10;
say $bar++;
}
As far as Perl 5 vs Perl 6, it is more like C++ vs C# + Haskell + various other languagesPerl 6 breaks backwards compatibility in all the ways that needed to be broken to modernize the syntax, and reduce special cases. Even infix operators are no longer special.
From what I can see Python 3 breaks backward compatibility for things it didn't really need to if they tried harder. (It would have made the implementation more difficult to work on.)
I think that you are overlooking the fact that the vast majority of python 2 code wouldn't run by default with python 3. Yes, there are now conversion utilities that handle most (all? maybe?) of the scenarios, but the fact remains that both Python 3 and Perl 6 break backwards compatibility.
C and C++ have tried very hard to not do this. Your old C code and your old C++ code will almost always compile as is with a newer standard.