There are many languages still in use today that have all kinds of warts and ugliness, but they remain in use because they still have momentum and lots of legacy things built in them. So being ugly or old isn’t enough of a factor for people to abandon something in droves.
Once you need to rewrite everything, there’s no reason to stay with something you know since you need to fully retool anyway.
As a Perl programmer since v5 was released, the confusion around 6 completely destroyed almost everyone’s enthusiasm, and immediately caused all new projects to avoid Perl. It seemed like 5 had reached the end of the line, and 6 was nowhere to be found. Nobody wants to gamble so many hours of their lives, and the future of their business, on such an uncertain environment.
If Perl 6 had any visible movement within the first few years, it might have survived, but it was a good decade before they even admitted Perl 6 might take longer than expected, and then more time after that before they admitted it should have been a new language. 6 was interesting for language geeks, and they probably did some cool things, but you can’t run a large popular project like it’s a small research project. That completely destroyed all momentum in the community. Perl 5 development only resumed far too late, after the writing was already on the wall.
Both Bill Gates and Linus understand backwards compatibility as a sacrosanct principle. Python only just barely survived the jump from 2 to 3. JavaScript can only survive this because there’s no other option in a browser.
I learned Python from reading a pocket language reference that just described the syntax and standard library, because the language was simple and easy to understand and everything made sense.
Conversely, I was trying to debug a script someone else ran and came across a line that said '$|++'; it was impossible to search for on the web, and when I asked on IRC the only answer I got was 'man perldoc' which also did not answer my question in any reasonable way.
For anyone wondering: `$|` is an alias for `$OUTPUT_AUTOFLUSH`; it defaults to 0 (line-buffered) but any non-zero value means 'flush output immediately'. Thus '$|++' changes 0 to 1 (or 1 to 2, etc), which means that '$|++' means 'turn off output buffering'. No one could be bothered to say that; if you had questions about the language you clearly didn't RTFM well enough so that became the default/only answer I ever saw.
Meanwhile, the PHP community was often welcoming and helpful to newcomers, despite most of them being bad at programming and giving bad advice, and the Python community produced a language that was so often self-explanatory that new user questions were more about how Python did things or asking about how to implement things they didn't realize were in the standard library.
So yeah, lots of things contributed to Perl's decline, but the community being a bunch of elitist toxic dicks sure didn't help matters and it meant that as the set of people looking to learn how to do programming on Linux grew past the neckbeards looking for any metric to show that they were better than other people then Perl's growth potential was finite.
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
man perldoc
perldoc -v '$|'
So it was actually reasonable advice.
But I also burned out relatively quickly. I’d happily answer new questions nicely, but the third or fourth time I saw the same question I spent much less effort to give a welcoming answer than I had the first time I saw it.
Of course, getting the same question repeatedly may suggest something should be redesigned.
I don’t know any good way to keep helpful volunteers helpful for a long time. The best idea I have is constantly recruiting new experts to continually replace the ones that burn out and chase off newbies.
Yes! There was a lesson in that and we all missed it. That was probably one of the failings of perl. It ran into a generation of people who never knew about "man pages", or couldn't read (jk - but only somewhat: for some people reading is very hard because various flavors of ADHD, dyslexia, executive disfunction, whatever) and the man page is then useless, or they go to google first and '$|++' failed (because google was raised on python).
Better marketing of the documentation would have helped.
I would say "we'll do better next time" but then perl 6... I'm not happy with perl 6 documentation. There is a lot of it - no problem there. But it insists on living online which necessitates a hosted search function. Which is always broken. And there is still no "local doc" solution.