Disclaimer. Perl was my first real language. I have several contributions to Perl, including a complete rewrite of Carp.pm. For a number of years I was also on the Perl 5 Grant Committee.

I completely discount the basic syntax as an issue. Sure, it is an easy thing to complain about. But I've personally seen a number of people with no background master the basic syntax very quickly. In fact I was able to teach myself from the Camel book with absolutely zero background in the various languages that are supposed to help you. And during the dot com era, most of the people writing CGI scripts in Perl, similarly lacked a programming background.

The first issue was the fact that a lot of bad Perl got written. It was remarkably easy to pick up a bit of Perl, then write a bunch of code. This code was generally bad, useful, and full of security holes. (Thanks, Matt Wright.) Most people's exposure to Perl was to this kind of code, and it left a permanent bad impression.

The TIMTOWTDI (There Is More Than One Way To Do It) philosophy fed into a widespread cowboy philosophy. People took pride in their mastery of Perl, and demonstrated it by using obscure features. Like, say, C++, many subsets of Perl make for good languages. But if you try to use all of the features at once, the combination doesn't play well together.

That said, there was a significant group of people who grew and improved together. They learned best practices, wrote good CPAN modules, and elevated their game. But this group fell into a different trap. They learned the immense productivity of small teams. But organizations filled with small teams of senior programmers, don't have a way to mentor junior programmers. This cut off the pipeline of future developers. Losing that pipeline is an organizational threat. How do you find maintenance programmers down the line? Many organizations that had a lot of Perl, then put a lot of work into trying to move away from Perl. A significant number of Perl programmers saw the writing on the wall, and took the opportunity to move away from Perl themselves. This resulted in very few new companies being built around Perl.

(Incidentally the same "no pathway for junior programmers" problem is becoming a big issue for programming in general because of LLMs.)

For the next problem, we have to go to perl5-porters. The group that maintained the core of the language.

Let's start with a key individual. Tom Christensen. Brilliant, productive, and a technical genius. But also confrontational, unstable, and a toxic influence that shut down Perl development. This was a major reason why the Perl 5.6.1 release took over a year to get important bug fixes out. Tom also drove a number of people out of the Perl core.

Then there was an underlying tension between two major groups. The first were people who wanted to take Perl, and run with it. Adding all sorts of new and interesting features. The opposing group was those who cared about production, and wanted to be reaaally careful about breaking anything.

This lead in 2000 to a famous cup throwing incident by Jon Orwant. Larry's solution was to behind the scenes put a muzzle on Tom, and start the Perl 6 effort. That way people who wanted new features could go off and play in the new sandbox, while those who wanted to support existing Perl could stay in Perl 5.

Over time a lot of the good ideas in the new sandbox got ported back to Perl. See, for example, Moose. The spread of these technologies meant that there was a lot of progress within the Perl ecosystem. Unfortunately this came as the Perl ecosystem itself was shrinking. The language itself improved a lot. But the programming world in general didn't notice, and didn't care.

Thanks for that perspective, Ben.