Most active commenters
  • MangoToupe(5)
  • JoshTriplett(4)

←back to thread

Perl's decline was cultural

(www.beatworm.co.uk)
393 points todsacerdoti | 13 comments | | HN request time: 1.298s | source | bottom
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. JoshTriplett ◴[] No.46175700[source]
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.

replies(3): >>46176212 #>>46176595 #>>46195461 #
2. MangoToupe ◴[] No.46176212[source]
> With the benefit of hindsight, though, Python 3 could have been done as a non-breaking upgrade.

Not without enormous and unnecessary pain.

replies(2): >>46176308 #>>46179478 #
3. JoshTriplett ◴[] No.46176308[source]
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.
replies(1): >>46179828 #
4. kstrauser ◴[] No.46176595[source]
That split between bytes and unicode made better code. Bytes are what you get from the network. Is it a PNG? A paragraph of text? Who knows! But in Python 2, you treated them both as the same thing: a series of bytes.

Being more or less forced to decode that series into a string of text where appropriate made a huge number of bugs vanish. Oops, forget to run `value=incoming_data.decode()` before passing incoming data to a function that expects a string, not a series of bytes? Boom! Thing is, it was always broken, but now it's visibly broken. And there was no more having to remember if you'd already .decode()d a value or whether you still needed to, because the end result isn't the same datatype anymore. It was so annoying to have an internal function in a webserver, and the old sloppiness meant that sometimes you were calling it with decoded strings and sometimes the raw bytes coming in over the wire, so sometimes it processed non-ASCII characters incorrectly, and if you tried to fix it by making it decode passed-in values, it start started breaking previously-working callers. Ugh, what a mess!

I hated the schism for about the first month because it broke a lot of my old, crappy code. Well, it didn't actually. It just forced me to be aware of my old, crappy code, and do the hard, non-automatable work of actually fixing it. The end result was far better than what I'd started with.

replies(1): >>46177133 #
5. JoshTriplett ◴[] No.46177133[source]
That distinction is indeed critical, and I'm not suggesting removing that distinction. My point is that you could give all those types names, and manage the transition by having Python 3 change the defaults (e.g. that a string is unicode).
replies(1): >>46177181 #
6. kstrauser ◴[] No.46177181{3}[source]
I’m a little confused. That’s basically with Python 3 did, right? In py2, “foo” is a string of bytes, and u”foo” is Unicode. In py3, both are Unicode, and bytes() is a string of bytes.
replies(1): >>46178847 #
7. JoshTriplett ◴[] No.46178847{4}[source]
The difference is that the two don't interoperate. You can't import a Python 3 module from Python 2 or vice versa; you have to use completely separate interpreters to run them.

I'm suggesting a model in which one interpreter runs both Python 2 and Python 3, and the underlying types are the same, so you can pass them between the two. You'd have to know that "foo" created in Python 2 is the equivalent of b"foo" created in Python 3, but that's easy enough to deal with.

replies(1): >>46179839 #
8. SoftTalker ◴[] No.46179478[source]
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.
replies(2): >>46179725 #>>46179848 #
9. ◴[] No.46179725{3}[source]
10. MangoToupe ◴[] No.46179828{3}[source]
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:
11. MangoToupe ◴[] No.46179839{5}[source]
Ok who would suggest this when the community could take a modicum of responsibility
12. MangoToupe ◴[] No.46179848{3}[source]
Yes, exactly. customers need to stop acting like a bitch if they wanna be taken seriously
13. zahlman ◴[] No.46195461[source]
Why would I ever risk inflicting a stack trace like

  Traceback (most recent call last):
    File "x.py", line 2, in <module>
      foo.encode()
  UnicodeDecodeError: 'ascii' codec can't decode byte 0xff in position 0: ordinal not in range(128)
on a user of Python 3.x where it isn't possible? (Note the UnicodeDecodeError coming from an attempt to encode.)