Perl's decline was cultural

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.

> 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.

Python 3 was a disaster and enterprises were still undertaking pointless 2->3 upgrade projects 10 years later

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

Python 3 couldn't even kill Python 2!

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.

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

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.

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

> 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.

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.

The real problem here was releasing 3.0 as if it was stable, when the real usable version was 3.3/3.4

It was not a disaster in any way. People just complained about having to do something to upgrade their codebases.

> With the benefit of hindsight, though, Python 3 could have been done as a non-breaking upgrade.

Not without enormous and unnecessary pain.

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.

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.

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.

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).

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.

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.

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.

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.

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:

Ok who would suggest this when the community could take a modicum of responsibility

Yes, exactly. customers need to stop acting like a bitch if they wanna be taken seriously

Differences of scale do make a qualitative difference and must be considered when doing a migration.

"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.

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.

Do you not think O'Reilly Associates fits some of that role? It seemed like Perl had more commercial backing compared to the other scripting languages if anything at that point. Python and JavaScript were picked up by Google, but later. Amazon was originally built out of Perl. Perl never converted its industry footprint into that kind of advocacy, I think some of that is also culture-driven.

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.

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.)

I recall 3.2 being okay. But it was definitely better by 3.4.

Maybe until the 2001 O'Reilly layoffs. Tim hired Larry for about 5 years, but that was mostly working on the third edition of the Camel. A handful of other Perl luminaries worked there at the same time (Jon Orwant, Nat Torkington).

When I joined in 2002, there were only a couple of developers in general, and no one sponsored to work on or evangelize any specific technology full time. Sometimes I wonder if Sun had more paid people working on Tcl.

I don't mean to malign or sideline the work anyone at ORA or ActiveState did in those days. Certainly the latter did more work to make Perl a first-class language on Windows than anyone. Yet that's very different from a funded Python Software Foundation or Sun supporting Java or the entire web browser industry funding JavaScript or....

Thanks for detailed reply. Yes, the marketing budget for Java was unmatched, but to my eye they were in retreat towards the Enterprise datacentre by 2001. I don't think the Python foundation had launched until 2001. Amazon was migrating off Perl and Oracle. JavaScript only got interesting after Google maps/Wave I think, arguably the second browser wars start when Apple launches Safari, late 2002.

So, I guess the counterfactual line of enquiry ought to be why Perl didn't, or couldn't, or didn't want, to pivot towards stronger commercial backing, sooner.