3 ms·

The changes Python made was made in Perl without breaking compatibility, you just wrote say use v5.24 in header to use given feature set (defaulted to som

by ilyt 4y ago

The changes Python made was made in Perl without breaking compatibility, you just wrote say use v5.24 in header to use given feature set (defaulted to something old to not break old stuff) The Py3 approach was terrible and wasted untold amount of hours just because you had to migrate everything, you couldn't just upgrade codebase piece by piece like in case of Perl. At the very least they should've just made new one be under .py3 and just make Python3 interpreter transpile Py2 code at runtime

linsomniac 4y ago
Isn't that effectively what was done with Python? You'd do "#!/usr/bin/env python" for old code and "#!/usr/bin/env python3" for new code. Rather than it being wrapped up in a single entry-point, you had the different runtimes and library sets.
- acqq 4y ago
  No, it's completely different. The newer Perl versions correctly continued to execute the old but already working scripts. The Python mess was, IMO, a typical example of bureaucracy inventing for itself new but previously unnecessary work to justify its existence, so I agree that that the decisions of how to introduce Py3 features caused (and still cause) waste of immense amount of the hours world-wide that could have been used more productively. Sad.
  - spicybright 4y ago
    For sure. I'd argue it was debatable to even "normalizing" all the built in packages to be consistent. I think very few people had trouble remembering them, and if you're using one, you'll be looking up documentation for anything with more than a few methods. It really is frustrating in these situations with high level languages. It's super possible to do the majority of changes they did in non breaking ways. Hell, they do it already with the __future__ package. Where did all that compatibility work go in python3?
  - toast0 4y ago
    > No, it's completely different. The newer Perl versions correctly continued to execute the old but already working scripts. There was some breakage between 5.6, 5.8, and 5.10; Unicode is hard, and it takes time to get it right. But I think the key difference I've heard as a mostly python avoider is the intent was for code written for 5.6 to probably work in 5.8 and 5.10 and if it doesn't, for there to be a way to have one file that works for all versions. From what I understand, it's not easy to have a python module/script that works in 2 and 3, and you can't go to 3 unless your dependencies do, so if you have a lot of dependencies (as is modern), you're stuck on 2. Your dependencies won't want to move to 3 either, because their users are stuck on 2, so if they just switch to 3, they're droping users; instead they need to support two parallel versions of their code. Most perl modules didn't have to do anything special to support 5.6 and 5.8, but if they did, it was usually small and it could be done within the file with conditional compilation --- I don't think that was an option for python.
- pjc50 4y ago
  > You'd do "#!/usr/bin/env python" for old code and "#!/usr/bin/env python3" for new code .. but you can't use old libraries in new code.
  - linsomniac 4y ago
    Just to clarify, in Perl you can have your main code be in Perl 6 (or whatever), and then "import" and use libraries that "use v5.26"?
    - wlonkly 4y ago
      No, Perl 6 is a completely different language (now called Raku, because otherwise it sounds like a newer version of Perl 5, and never intended to be compatible with Perl 5). But because of the Perl 6 situation, even a change the size of the Python 2 to 3 change would be a "Perl 5" version update. I think having Python 2 vs. 3 is a clearer demarcation, myself, but the Perl community cares a LOT about backwards compatibility.
- mort96 4y ago
  The people working on Perl still support running in old mode. You can grab the latest Perl 5 release and run old-style Perl code in it. The people behind Python don't support Python 2.
  - linsomniac 4y ago
    Just because the old way was deprecated doesn't mean that it wasn't possible to run old and new code next to each other. Also, Perl 5 is a very different example. While I haven't followed Perl for quite a while, ISTR that Perl had a very similar transition from 4->5 (I personally remember spending a lot of time trying to get old code working on newer OSes). Also, AFAIK but I may be wrong, Perl 6 has not really taken off like Python 3 did.
danaris 4y ago
Yes; and now we have to keep every version of Perl around in our package managers because they're all used by some code. That's terrible practice.
- sharpneli 4y ago
  That means the piece of software will work also in the future. Personally I only use python for throwaway scripts. Whatever is written in Python likely won’t work in 10 years anymore. So they’re all lost in time. Whereas I can continue some of my C++ eternity projects and they still work perfectly fine.
- amiga386 4y ago
  You don't. The directives in Perl code tell the Perl interpreter, even the very latest one and it's the only one installed on your machine, how it should intepret loading the code. If you don't write special in your code, Perl doesn't have a "say" method (because it didn't have one in Perl 5.8). If you declare in the code that you're code for Perl 5.10, magically there are all the Perl 5.10 features, including "say". You can also declare you want specific features, rather than declare a specific Perl version. $ perl -v | head -2 | tail -1 This is perl 5, version 30, subversion 3 (v5.30.3) built for x86_64-cygwin-threads-multi $ perl -e 'say 1' Number found where operator expected at -e line 1, near "say 1" (Do you need to predeclare say?) syntax error at -e line 1, near "say 1" Execution of -e aborted due to compilation errors. $ perl -e 'use 5.010; say 1' 1 $ perl -e 'use feature "say"; say 1' 1 The best thing about this is you can mix and match libraries from earlier and newer Perl versions. If a library says they want Perl 5.10, they get Perl 5.10, even if you want both Perl 5.30 and that library. If only Python were as reliable for backwards compatibility. The Perl community is going through their own Py2->3 moment, and they're doing it with great care. They're going to create Perl 7, which will be Perl 5 where the "defaults" make the language look more like Perl 5.32 rather than Perl 5.8 [1]. Modern Perl scripts don't need so much boilerplate to enable modern features. They know exactly the trouble this will cause; if Perl 7 ever becomes the default Perl interpreter, the only one, it _will not run_ lots of very old Perl scripts untouched, because the defaults will make years worth of language changes suddenly visible to those scripts. Even if the fix is just to slap "use 5.008" on every script, they worry about it. That's a much better attitude than the Python developers. [1] https://www.perl.com/article/announcing-perl-7/ https://www.perl.com/article/announcing-perl-7/

by ilyt 4y ago

linsomniac 4y ago

Isn't that effectively what was done with Python? You'd do "#!/usr/bin/env python" for old code and "#!/usr/bin/env python3" for new code. Rather than it being wrapped up in a single entry-point, you had the different runtimes and library sets.

acqq 4y ago
No, it's completely different. The newer Perl versions correctly continued to execute the old but already working scripts. The Python mess was, IMO, a typical example of bureaucracy inventing for itself new but previously unnecessary work to justify its existence, so I agree that that the decisions of how to introduce Py3 features caused (and still cause) waste of immense amount of the hours world-wide that could have been used more productively. Sad.
- spicybright 4y ago
  For sure. I'd argue it was debatable to even "normalizing" all the built in packages to be consistent. I think very few people had trouble remembering them, and if you're using one, you'll be looking up documentation for anything with more than a few methods. It really is frustrating in these situations with high level languages. It's super possible to do the majority of changes they did in non breaking ways. Hell, they do it already with the __future__ package. Where did all that compatibility work go in python3?
- toast0 4y ago
  > No, it's completely different. The newer Perl versions correctly continued to execute the old but already working scripts. There was some breakage between 5.6, 5.8, and 5.10; Unicode is hard, and it takes time to get it right. But I think the key difference I've heard as a mostly python avoider is the intent was for code written for 5.6 to probably work in 5.8 and 5.10 and if it doesn't, for there to be a way to have one file that works for all versions. From what I understand, it's not easy to have a python module/script that works in 2 and 3, and you can't go to 3 unless your dependencies do, so if you have a lot of dependencies (as is modern), you're stuck on 2. Your dependencies won't want to move to 3 either, because their users are stuck on 2, so if they just switch to 3, they're droping users; instead they need to support two parallel versions of their code. Most perl modules didn't have to do anything special to support 5.6 and 5.8, but if they did, it was usually small and it could be done within the file with conditional compilation --- I don't think that was an option for python.
pjc50 4y ago
> You'd do "#!/usr/bin/env python" for old code and "#!/usr/bin/env python3" for new code .. but you can't use old libraries in new code.
- linsomniac 4y ago
  Just to clarify, in Perl you can have your main code be in Perl 6 (or whatever), and then "import" and use libraries that "use v5.26"?
  - wlonkly 4y ago
    No, Perl 6 is a completely different language (now called Raku, because otherwise it sounds like a newer version of Perl 5, and never intended to be compatible with Perl 5). But because of the Perl 6 situation, even a change the size of the Python 2 to 3 change would be a "Perl 5" version update. I think having Python 2 vs. 3 is a clearer demarcation, myself, but the Perl community cares a LOT about backwards compatibility.
mort96 4y ago
The people working on Perl still support running in old mode. You can grab the latest Perl 5 release and run old-style Perl code in it. The people behind Python don't support Python 2.
- linsomniac 4y ago
  Just because the old way was deprecated doesn't mean that it wasn't possible to run old and new code next to each other. Also, Perl 5 is a very different example. While I haven't followed Perl for quite a while, ISTR that Perl had a very similar transition from 4->5 (I personally remember spending a lot of time trying to get old code working on newer OSes). Also, AFAIK but I may be wrong, Perl 6 has not really taken off like Python 3 did.

danaris 4y ago

Yes; and now we have to keep every version of Perl around in our package managers because they're all used by some code. That's terrible practice.

sharpneli 4y ago
That means the piece of software will work also in the future. Personally I only use python for throwaway scripts. Whatever is written in Python likely won’t work in 10 years anymore. So they’re all lost in time. Whereas I can continue some of my C++ eternity projects and they still work perfectly fine.
amiga386 4y ago
You don't. The directives in Perl code tell the Perl interpreter, even the very latest one and it's the only one installed on your machine, how it should intepret loading the code. If you don't write special in your code, Perl doesn't have a "say" method (because it didn't have one in Perl 5.8). If you declare in the code that you're code for Perl 5.10, magically there are all the Perl 5.10 features, including "say". You can also declare you want specific features, rather than declare a specific Perl version. $ perl -v | head -2 | tail -1 This is perl 5, version 30, subversion 3 (v5.30.3) built for x86_64-cygwin-threads-multi $ perl -e 'say 1' Number found where operator expected at -e line 1, near "say 1" (Do you need to predeclare say?) syntax error at -e line 1, near "say 1" Execution of -e aborted due to compilation errors. $ perl -e 'use 5.010; say 1' 1 $ perl -e 'use feature "say"; say 1' 1 The best thing about this is you can mix and match libraries from earlier and newer Perl versions. If a library says they want Perl 5.10, they get Perl 5.10, even if you want both Perl 5.30 and that library. If only Python were as reliable for backwards compatibility. The Perl community is going through their own Py2->3 moment, and they're doing it with great care. They're going to create Perl 7, which will be Perl 5 where the "defaults" make the language look more like Perl 5.32 rather than Perl 5.8 [1]. Modern Perl scripts don't need so much boilerplate to enable modern features. They know exactly the trouble this will cause; if Perl 7 ever becomes the default Perl interpreter, the only one, it _will not run_ lots of very old Perl scripts untouched, because the defaults will make years worth of language changes suddenly visible to those scripts. Even if the fix is just to slap "use 5.008" on every script, they worry about it. That's a much better attitude than the Python developers. [1] https://www.perl.com/article/announcing-perl-7/ https://www.perl.com/article/announcing-perl-7/