It's interesting because you can still find interviews of Larry online how Perl is the first postmodern programming language but for perl6 they came up with a very top-down, modernist project

And killing Perl 5 in the process. If Perl would have kept going in its own pace and Perl 6 would have been named Rapture or Raku from day one, Perl would have been fine.

Nowadays when everyone and their dog (vcpkg) have a package system, it’s easy to overlook how magical CPAN was. A solution to the weirdest problem, just a package away.

> I really don't think Python was close to dying

It absolutely was. What saved it was:

1. The data science / AI crowd that was gathering momentum any many only used Python 3.

2. No popular alternative. Perl got python as an alternative.

Python was also a good, simple language and had a good healthy culture. But it's nothing sort of a miracle that it survived that biblical software calamity.

I know companies with a big Python 2 stack that rather preferred to rewrite in typescript than migrate to Python 3

I turned down one of those companies because I didn’t want to deal with that migration in 2021

If Golang was around, it might have killed python then I think. To many, the 2->3 jump made little sense. I honestly wish they just started a new language instead.

I still to this day stumble upon code I have to use 2.7 on, thankfully things like pipx make it easy these days. but still,switching back and forth could be a pain.

But you're right, it wasn't like Perl 6. People moved to python and php mostly from perl. what were going to move to from python 2? Ruby?

Can you imagine if the PSF had been working on Python 4 in parallel, with more backwards compat shifts or even a radically modified syntax?

I think another saving grace was, when considering Python 3, one's choice was between "easy-ish migration to best in class" and "difficult rewrite into second-best". Meanwhile with Perl 5/6 it was "two moderately hard migrations into metastasized shell-script has-been language" and "difficult rewrite into best-in-class with lots of upside".

> Python 2 to 3 took a really long time

It took AdaCore so long to port the plugin system of the GNAT Studio (GPS) to Python 3 (which seems to be a fraction of the whole code base), that even conservative Debian had to remove the whole GNAT-GPS package.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1082332

The delta between python 2 and 3 was much smaller than the delta between perl 5 and 6. Perl 6 might as well be a totally different langue which is probably why they renamed it to Raku, to stop people thinking that it was the same language.

> There was always a clear way forward and people were actually moving.

I was always of the impression that people were very reluctant to move even though the benefits were clear and the movement not nearly as difficult as people claimed. But I still hear people complain about, for example, how you can't run CPython 2.x bytecode on a modern CPython runtime even though you can't run CPython 3.13 bytecode on a CPython 3.14 runtime, either and that hasn't slowed anyone down at all.

Python continued growing fast during the 2 to 3 transition, it was nowhere near dying. It was one reason it took so long, people were starting new Python 2 projects 5 years after Python 3 was released. Only around 2017/2018 the default for new projects kind of became Python 3.

I agree

If anything might have killed python it was not python 3 per se but shipping a "beta" version of Py3 as 3.0

Python 3 only got usable really around 3.3 or maybe 3.4

My take is a lot of that Web 1.0 stuff was total spaghetti code, hardcoded to a table layout, full of injection holes, etc etc. (It was like everyone did my first CGI script x 100.) So in that sense Perl wasn't any different than classic ASP or cold fusion or etc, it became associated with bad legacy code. And because there was no 'Perl 6', people had to choose something else.

(There's stuff about the perl language, but that's probably secondary.)

Yea, Perl thrived while there was no real alternative.

PHP arrived and ate into it's web app use-cases. Modperl wasn't great for hosted environments, to say the least.

Python matured and started eating into it's systems use-cases and eventually the web use-cases as well. And was just so much easier to work with and learn.

Perl was left with no real niche where it really shined, except one-liners and making poetry I guess

A completely different language, a decade of development to Perl 6, and Python eating its lunch in the meantime. Perl is often called a write only language, and there's Python with

    for line in file:

> well, we never specified _which_ Christmas.

The wider Perl community adopted that, and for years it was a running joke that Perl 6 would be "out by Christmas."

Of course, people outside the Perl community didn't get the joke. They just perceived it as the Perl community making promises about release dates and then missing them. That was some self-inflicted damage.

I think more specifically it was the hesitance to move Perl 5 significantly forward in the meantime that caused the damage. That has been decidedly changed the last few years, with great strides being made. That time in between is lost, though.

Perl was not and still is not suitable for people who refuse to read the manual or tutorial.

Perl had and still has truly AMAZING documentation (and far better in perl 5 than Perl 6 - where the documentation's search function is regularly broken for example). And out of this world bring-up tutorials. But if the bar is at "I want to be up to speed after reading a short booklet" - well, that's not gonna work. For me I have programmed in perl for decades and I still get the occasional deep plunge in a feature area that I never used before... And the various docs and books still come through.

On top of that, Perl 5 had an amazing community ready to help - but understandably annoyed with constantly re-quoting the AMAZING documentation. It could have gone either way, it just went the way it did: experts present and ready to answer. But there too - if you expect the community to constantly answer the most basic questions, well, Perl was not for you.

As a tradeoff perhaps, that expert community also spent a lot of effort on the AMAZING module library.

Perl 5's thorough documentation, plus splendid course book, plus all the books, plus CPAN, PLUS the expert help producing fantastic rabbit holes to learn more about your PROFESSIONAL MEDIUM. THAT was the reason for choosing perl.

If anything, newcomers don't go to the documentation because they are not aware that documentation can be THAT good. That was, still is, a marketing error.

> the only answer I got was 'man perldoc'

When I asked a question on the PERL Usenet group in the 90s, I used the word "newbie" to describe my skill level. I got an automated email explaining why I shouldn't use that word.

> when I asked on IRC the only answer I got was 'man perldoc'

Your overall point notwithstanding, this was just bad advice. What you want is `man perlvar` (or equivalently `perldoc perlvar`) which documents this and other predefined variables:

       HANDLE->autoflush( EXPR )
       $OUTPUT_AUTOFLUSH
       $|      If set to nonzero, forces a flush right away and after every
               write or print on the currently selected output channel.
               Default is 0 (regardless of whether the channel is really
               buffered by the system or not; $| tells you only whether you've
               asked Perl explicitly to flush after each write).  STDOUT will
               typically be line buffered if output is to the terminal and
               block buffered otherwise.  Setting this variable is useful
               primarily when you are outputting to a pipe or socket, such as
               when you are running a Perl program under rsh and want to see
               the output as it's happening.  This has no effect on input
               buffering.  See "getc" in perlfunc for that.  See "select" in
               perlfunc on how to select the output channel.  See also
               IO::Handle.

               Mnemonic: when you want your pipes to be piping hot

Sorry for the bad experience you had, I believe it's always better to be kind to strangers on those global nets. But TBH perldoc would really work very well for you.

This is so spot on. You can't google line noise, and that mattered before LLMs. And everything else you said.

You can co-exist. That's the best path forward for breaks IMO.

Rust does this with "editions". That's where they can make breaks to the language. 2021 can still call 2017 edition code.

Perl actually had this as well with Perl 5. You could specify the version of the perl file and work from there.

Why they didn't do that with 6 was entirely bizarre. They basically promised to throw out all of CPAN with the next perl version.

Well, what Perl code is not real-world? And by ugly you mean what - not verbose or what? Something is ugly for ones, but nice to others. I doubt that really is a factor driving a demise of language, otherwise features like regexes would be non-existent today.