←back to thread

Perl's decline was cultural

(www.beatworm.co.uk)
393 points todsacerdoti | 3 comments | | HN request time: 0.242s | source
Show context
deafpolygon ◴[] No.46175307[source]
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.

replies(6): >>46175362 #>>46175400 #>>46175465 #>>46175553 #>>46175645 #>>46185055 #
MangoToupe ◴[] No.46175362[source]
> 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.

replies(2): >>46175397 #>>46175805 #
symbogra ◴[] No.46175397[source]
Python 3 was a disaster and enterprises were still undertaking pointless 2->3 upgrade projects 10 years later
replies(4): >>46175504 #>>46175516 #>>46176206 #>>46177968 #
jordanb ◴[] No.46175504[source]
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.

replies(2): >>46175685 #>>46175700 #
1. xscott ◴[] No.46175685[source]
> 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.

replies(2): >>46176219 #>>46195411 #
2. MangoToupe ◴[] No.46176219[source]
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.
3. zahlman ◴[] No.46195411[source]
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.