Barely. The subset of code that works in both Python 2.6+ and 3.3+ is orders of magnitude greater than the subset of code that works in both Perl 5 and 6.
Well, as you pointed out, Python 3 differs from Python 2 only with minor languages changes.
Perl 6 is drastically different from Perl 5 (though clearly in the same lineage). Not only the language is quite different, but so is the design of the implementation.
Not at all. Unlike Perl 6, Python 3 1) exists 2) has a significant amount of library support and 3) is clearly intended to supplant Python 2. None of those points apply to Perl 6.
It is different, all of the differences between Python 2 & 3 seem like the difference from one version of Perl 5 to another as far as I can tell. The main thing is Perl 5 tries to remain mostly backward compatible. I have heard of one company switching back to Perl 5 after switching to various “fad” languages for this very reason. (I wasn't told which company it was, likely because of an NDA) There have occasionally been bugs that P5P were hesitant to remove because someone might be relying on them.
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 languages
Perl 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 can attest to this. This was my first insight into the Perl 5/6 issue. Until now, I always assumed it was along the lines of Python 2.x and Python 3.
> Perl is also moving forward, it's just doing so differently than Python. Python has major releases like 2.6 and 3.0 where they explicitly break old code in the default installation.
3.0 yes, but 2.6 is simply not true. code written for 2.2 will work in 2.6, bugs notwithstanding.
You're either misunderstanding Python 3 or misunderstanding Perl 6.
Python 3 was a few breaking changes made to Python 2.
Perl 6 was a completely new language, designed from scratch, with little in common with Perl 5 aside from bits of syntax. It still doesn't have a "complete" release, in 14 years. In half that time, we've had a Python 3.0 and four more point releases.
I love Perl [I have been to perl monger meetings and I had to look up how to 'unshift' in python today].
But Python3 is mostly just Python2 with a print function instead of a print keyword. It is occasionally non-trivial to port large existing code bases from Python2 to Python3, but it is practically always trivial for a Python2 programmer to write new code in Python3.
> I am just applying the same principles to Python what
> used to be applied to Perl.
No, there are some significant differences between the two which your commentary misses, like the fact that python3 ecosystem and the path for migration to it is far more mature than perl6's is (or likely ever will be, the way things are going.)
I'm not extremely familiar with Perl 6 to be able to draw a comparison.
From what I know about Python 2/3, it's that you can write maybe 90% on average/in general of your code the same way without much thought about the differences. However, if you do wish to adopt the new features, there's plenty to keep you busy writing scripts for at least a few months, maybe even a year.
reply