3 ms·

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 bein

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.

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.