4 ms·

I think the Python 2->3 and Perl 5->6 _is_ different from GCC supporting different C standards. I think that you are overlooking the fact that the vast majorit

by eej71 9y ago

I think the Python 2->3 and Perl 5->6 _is_ different from GCC supporting different C standards. 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.

cygx 9y ago
Your old C code and your old C++ code will almost always compile as is with a newer standard. 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.
- raiph 9y ago
  If you browse the #perl6-toolchain logs[1] you'll see folk making steady progress toward practical interop of multiple versions of the P6 language (6.c, 6.d, etc.), P6 compilers (Rakudo 2017.07 etc.), and P6 modules on the one hand and hosting this stuff on CPAN on the other. But perhaps you know about that already. 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? [1] https://irclog.perlgeek.de/perl6-toolchain https://irclog.perlgeek.de/perl6-toolchain
b2gills 9y ago
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.)
gkya 9y ago
Correct, but practically, it doesn't matter. If you compile C89, you use gcc in that mode, if C11, similarly. With Python, if you want Python 2, you run Python 2, if 3, Python 3. Backwards compatibility is another issue. IDK if people really build say C89 code with C99 or C11 compilers or use multiple standards concurrently in a given project.

by eej71 9y ago

cygx 9y ago

Your old C code and your old C++ code will almost always compile as is with a newer standard. 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.

raiph 9y ago
If you browse the #perl6-toolchain logs[1] you'll see folk making steady progress toward practical interop of multiple versions of the P6 language (6.c, 6.d, etc.), P6 compilers (Rakudo 2017.07 etc.), and P6 modules on the one hand and hosting this stuff on CPAN on the other. But perhaps you know about that already. 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? [1] https://irclog.perlgeek.de/perl6-toolchain https://irclog.perlgeek.de/perl6-toolchain

b2gills 9y ago

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.)

gkya 9y ago

Correct, but practically, it doesn't matter. If you compile C89, you use gcc in that mode, if C11, similarly. With Python, if you want Python 2, you run Python 2, if 3, Python 3. Backwards compatibility is another issue. IDK if people really build say C89 code with C99 or C11 compilers or use multiple standards concurrently in a given project.