3 ms·

Perl6/Raku killed Perl. Python 3 almost killed Python. It's normal. Once a community loses faith, it's hard to stop them from leaving.

MangoToupe 10mo ago
> Python 3 almost killed Python. People were being crybabies; the critics were extremely vocal and few. Python 3 improved the language in every way and the tooling to upgrade remains unmatched.
- symbogra 10mo ago
  Python 3 was a disaster and enterprises were still undertaking pointless 2->3 upgrade projects 10 years later
  - jordanb 10mo ago
    It was annoying but if it hadn't happened Python would still be struggling with basic things like Unicode. Organizations struggled with it but they struggle with basically every breaking change. I was on the tooling team that helped an organization handle the transition of about 5 million lines of data science code from python 2.7 to 3.2. We also had to handle other breaking changes like airflow upgrades, spark 2->3, intel->amd->graviton. At that scale all those changes are a big deal. Heck even the pickle protocol change in Python 3.8 was a big deal for us. I wouldn't characterize the python 2->3 transition as a significantly bigger deal than some of the others. In many ways it was easier because so much hay was made about it there was a lot of knowledge and tooling.
    - xscott 10mo ago
      > It was annoying but if it hadn't happened Python would still be struggling with basic things like Unicode. They should've just used Python 2's strings as UTF-8. No need to break every existing program, just deprecate and discourage the old Python Unicode type. The new Unicode type (Python 3's string) is a complicated mess, and anyone who thinks it is simple and clean isn't aware of what's going on under the hood. Having your strings be a simple array of bytes, which might be UTF-8 or WTF-8, seems to be working out pretty well for Go.
      - MangoToupe 10mo ago
        I can't say i've ever thought "wow I wish I had to use go's unicode approach". The bytes/str split is the cleanest approach of any runtime I've seen.
      - zahlman 10mo ago
        What you propose would have, among other things, broken the well established expectation of random access for strings, including for slicing, while leaving behind unclear semantics about what encoding was used. (If you read in data in a different encoding and aren't forced to do something about it before passing it to a system that expects UTF-8, that's a recipe for disaster.) It would also leave unclear semantics for cases where the underlying bytes aren't valid UTF-8 data (do you just fail on every operation? Fail on the ones that happen to encounter the invalid bytes?), which in turn is also problematic for command-line arguments.
    - JoshTriplett 10mo ago
      With the benefit of hindsight, though, Python 3 could have been done as a non-breaking upgrade. Imagine if the same interpreter supported both Python 3 and Python 2. Python 3 code could import a Python 2 module, or vice versa. Codebases could migrate somewhat more incrementally. Python 2 code's idea of a "string" would be bytes, and python 3's idea of a "string" would be unicode, but both can speak the other's language, they just have different names for things, so you can migrate.
      - MangoToupe 10mo ago
        > With the benefit of hindsight, though, Python 3 could have been done as a non-breaking upgrade. Not without enormous and unnecessary pain.
        JoshTriplett 10mo ago
        It would absolutely have been harder. But the pain of going that path might potentially have been less than the pain of the Python 2 to Python 3 transition. Or, possibly, it wouldn't have been; I'm not claiming the tradeoff is obvious even in hindsight here.
        MangoToupe 10mo ago
        I think you have causation reversed: it would have been at least two orders of magnitude greater to act like moving to python 3 was harder than staying. But you do you boo :emoji-kissey-face:
        SoftTalker 10mo ago
        Pain on whose part? There was certainly pain porting all the code that had to be ported to Python 3 so that the Python developers could have an easier time.
        deleted 10mo ago
        [deleted]
        10mo ago
  - zihotki 10mo ago
    A month ago I had to fix a small bug in Python 2.6 code in one of internal systems. It won't be ever migrated, no capacity and no value
  - MangoToupe 10mo ago
    It was not a disaster in any way. People just complained about having to do something to upgrade their codebases.
  - bsder 10mo ago
    Except that Python took the other path when migrating from Python 1 to Python 2 and ... guess what? That was a "disaster" too. The only difference was that by the time of Python 3, Python programs were orders of magnitude bigger so the pain was that much worse.
    - symbogra 10mo ago
      Differences of scale do make a qualitative difference and must be considered when doing a migration.
- raverbashing 10mo ago
  The real problem here was releasing 3.0 as if it was stable, when the real usable version was 3.3/3.4
  - zahlman 10mo ago
    I recall 3.2 being okay. But it was definitely better by 3.4.
symbogra 10mo ago
Agree 100%. We were told to wait for any improvements or new features we wanted and just to wait for Perl 6, which never came
ajross 10mo ago
Python 3 couldn't even kill Python 2!
o11c 10mo ago
I'd take this a step further and say that the design flaws that motivated Perl6 were what really killed Perl. Perl6 just accelerated the timeline. I do imagine a saner migration could've been done - for example, declaring that regexes must not start with a non-escaped space and division must be surrounded by space, to fix one of the parsing problems - with the usual `use` incremental migration.
Todd 10mo ago
Yep. Perl 6 was a wall that Perl 5 would never move beyond. It’s still Perl 5 25 years later.
topspin 10mo ago
"Perl6/Raku killed Perl." Perl was effectively "dead" before Perl 6 existed. I was there. I bought the books, wrote the code, hung out in #perl and followed the progress. I remember when Perl 6 was announced. I remember barely caring by that time, and I perceived that I was hardly alone. Everyone had moved on by then. At best, Perl 6 was seen as maybe Perl making a "come back." Java, and (by extension) Windows, killed Perl. Java promised portability. Java had a workable cross-platform GUI story (Swing). Java had a web story with JSP, Tomcat, Java applets, etc. Java had a plausible embedded and mobile story. Java wasn't wedded to the UNIX model, and at the time, Java's Windows implementation was as least as good as its non-Windows implementations, if not better. Java also had a development budget, a marketing budget, and the explicit blessing of several big tech giants of the time. In the late 90's and early 2000's, Java just sucked the life out of almost everything else that wasn't a "systems" or legacy big-iron language. Perl was just another casualty of Java. Many of the things that mattered back then either seem silly today or have been solved with things other than Java, but at the time they were very compelling. Could Perl have been saved? Maybe. The claims that Perl is difficult to learn or "write only" aren't true: Perl isn't the least bit difficult. Nearly every Perl programmer on Earth is self-taught, the documentation is excellent and Google has been able to answer any basic Perl question one might have for decades now. If Perl had somehow bent itself enough to make Windows a first-class platform, it would have helped a lot. If Perl had provided a low friction, batteries-included de facto standard web template and server integration solution, it would have helped a lot as well. If Perl had a serious cross-platform GUI story, that would helped a lot. To the extent that the Perl "community" was somehow incapable of these things, we can call the death of Perl a phenomena of "culture." I, however, attribute the fall of Perl to the more mundane reason that Perl had no business model and no business advocates.
- chromatic 10mo ago
  Excellent point in the last paragraph. Python, JavaScript, Rust, Swift, and C# all have/had business models and business advocates in a way that Perl never did.
  - colinstrickland 10mo ago

MangoToupe 10mo ago

> Python 3 almost killed Python. People were being crybabies; the critics were extremely vocal and few. Python 3 improved the language in every way and the tooling to upgrade remains unmatched.

symbogra 10mo ago
Python 3 was a disaster and enterprises were still undertaking pointless 2->3 upgrade projects 10 years later
- jordanb 10mo ago
  It was annoying but if it hadn't happened Python would still be struggling with basic things like Unicode. Organizations struggled with it but they struggle with basically every breaking change. I was on the tooling team that helped an organization handle the transition of about 5 million lines of data science code from python 2.7 to 3.2. We also had to handle other breaking changes like airflow upgrades, spark 2->3, intel->amd->graviton. At that scale all those changes are a big deal. Heck even the pickle protocol change in Python 3.8 was a big deal for us. I wouldn't characterize the python 2->3 transition as a significantly bigger deal than some of the others. In many ways it was easier because so much hay was made about it there was a lot of knowledge and tooling.
  - xscott 10mo ago
    > It was annoying but if it hadn't happened Python would still be struggling with basic things like Unicode. They should've just used Python 2's strings as UTF-8. No need to break every existing program, just deprecate and discourage the old Python Unicode type. The new Unicode type (Python 3's string) is a complicated mess, and anyone who thinks it is simple and clean isn't aware of what's going on under the hood. Having your strings be a simple array of bytes, which might be UTF-8 or WTF-8, seems to be working out pretty well for Go.
    - MangoToupe 10mo ago
      I can't say i've ever thought "wow I wish I had to use go's unicode approach". The bytes/str split is the cleanest approach of any runtime I've seen.
    - zahlman 10mo ago
      What you propose would have, among other things, broken the well established expectation of random access for strings, including for slicing, while leaving behind unclear semantics about what encoding was used. (If you read in data in a different encoding and aren't forced to do something about it before passing it to a system that expects UTF-8, that's a recipe for disaster.) It would also leave unclear semantics for cases where the underlying bytes aren't valid UTF-8 data (do you just fail on every operation? Fail on the ones that happen to encounter the invalid bytes?), which in turn is also problematic for command-line arguments.
  - JoshTriplett 10mo ago
    With the benefit of hindsight, though, Python 3 could have been done as a non-breaking upgrade. Imagine if the same interpreter supported both Python 3 and Python 2. Python 3 code could import a Python 2 module, or vice versa. Codebases could migrate somewhat more incrementally. Python 2 code's idea of a "string" would be bytes, and python 3's idea of a "string" would be unicode, but both can speak the other's language, they just have different names for things, so you can migrate.
    - MangoToupe 10mo ago
      > With the benefit of hindsight, though, Python 3 could have been done as a non-breaking upgrade. Not without enormous and unnecessary pain.
      - JoshTriplett 10mo ago
        It would absolutely have been harder. But the pain of going that path might potentially have been less than the pain of the Python 2 to Python 3 transition. Or, possibly, it wouldn't have been; I'm not claiming the tradeoff is obvious even in hindsight here.
        MangoToupe 10mo ago
        I think you have causation reversed: it would have been at least two orders of magnitude greater to act like moving to python 3 was harder than staying. But you do you boo :emoji-kissey-face:
      - SoftTalker 10mo ago
        Pain on whose part? There was certainly pain porting all the code that had to be ported to Python 3 so that the Python developers could have an easier time.
        deleted 10mo ago
        [deleted]
        10mo ago
- zihotki 10mo ago
  A month ago I had to fix a small bug in Python 2.6 code in one of internal systems. It won't be ever migrated, no capacity and no value
- MangoToupe 10mo ago
  It was not a disaster in any way. People just complained about having to do something to upgrade their codebases.
- bsder 10mo ago
  Except that Python took the other path when migrating from Python 1 to Python 2 and ... guess what? That was a "disaster" too. The only difference was that by the time of Python 3, Python programs were orders of magnitude bigger so the pain was that much worse.
  - symbogra 10mo ago
    Differences of scale do make a qualitative difference and must be considered when doing a migration.
raverbashing 10mo ago
The real problem here was releasing 3.0 as if it was stable, when the real usable version was 3.3/3.4
- zahlman 10mo ago
  I recall 3.2 being okay. But it was definitely better by 3.4.

symbogra 10mo ago

Agree 100%. We were told to wait for any improvements or new features we wanted and just to wait for Perl 6, which never came

ajross 10mo ago

Python 3 couldn't even kill Python 2!

o11c 10mo ago

I'd take this a step further and say that the design flaws that motivated Perl6 were what really killed Perl. Perl6 just accelerated the timeline. I do imagine a saner migration could've been done - for example, declaring that regexes must not start with a non-escaped space and division must be surrounded by space, to fix one of the parsing problems - with the usual `use` incremental migration.

Todd 10mo ago

Yep. Perl 6 was a wall that Perl 5 would never move beyond. It’s still Perl 5 25 years later.

topspin 10mo ago

"Perl6/Raku killed Perl." Perl was effectively "dead" before Perl 6 existed. I was there. I bought the books, wrote the code, hung out in #perl and followed the progress. I remember when Perl 6 was announced. I remember barely caring by that time, and I perceived that I was hardly alone. Everyone had moved on by then. At best, Perl 6 was seen as maybe Perl making a "come back." Java, and (by extension) Windows, killed Perl. Java promised portability. Java had a workable cross-platform GUI story (Swing). Java had a web story with JSP, Tomcat, Java applets, etc. Java had a plausible embedded and mobile story. Java wasn't wedded to the UNIX model, and at the time, Java's Windows implementation was as least as good as its non-Windows implementations, if not better. Java also had a development budget, a marketing budget, and the explicit blessing of several big tech giants of the time. In the late 90's and early 2000's, Java just sucked the life out of almost everything else that wasn't a "systems" or legacy big-iron language. Perl was just another casualty of Java. Many of the things that mattered back then either seem silly today or have been solved with things other than Java, but at the time they were very compelling. Could Perl have been saved? Maybe. The claims that Perl is difficult to learn or "write only" aren't true: Perl isn't the least bit difficult. Nearly every Perl programmer on Earth is self-taught, the documentation is excellent and Google has been able to answer any basic Perl question one might have for decades now. If Perl had somehow bent itself enough to make Windows a first-class platform, it would have helped a lot. If Perl had provided a low friction, batteries-included de facto standard web template and server integration solution, it would have helped a lot as well. If Perl had a serious cross-platform GUI story, that would helped a lot. To the extent that the Perl "community" was somehow incapable of these things, we can call the death of Perl a phenomena of "culture." I, however, attribute the fall of Perl to the more mundane reason that Perl had no business model and no business advocates.

chromatic 10mo ago
Excellent point in the last paragraph. Python, JavaScript, Rust, Swift, and C# all have/had business models and business advocates in a way that Perl never did.
- colinstrickland 10mo ago