zlacker

My hypothesis is that as the volume of Perl grew, it became more and more apparent that it wasn't a good idea to write new projects in Perl:

- Perl's fascination with punctuation makes it hard to google for stuff, since search engines strip punctuation. In an era of RTFM and grep, maybe this is okay, but puts the language at a substantial disadvantage vs languages that use more prose than punctuation

- The distinction between scalar vs array context is subtle and feels somewhat pointless if you learned a language like C or JavaScript first. C has no overloads but manages to work fine, and other scripting languages like JS or Python let you branch on the runtime type of variables explicitly. Why bother with array context?

- Similarly, people got used to having named function arguments in their function signatures. Maybe in an era where most code was either compiled (and had named function args), or was stringly-typed and scripting like Bash, Perl feels like more of the same. But once we started getting decent scripting languages that had named function args, it became a real pain to repeat basic stuff like "assign parameter 1 to variable $name, assign parameter 2 to variable $age" in every function. I wish shells would bite the bullet and figure out a way to adopt them.

Overall, our industry is moving towards larger scale and complexity, and at larger scales, reading and maintaining code is more important than writing code. Perl's language design choices are all balanced for 1-10 unix wizard authors having fun writing small scale scripts. Compare it to Java, the Anti-Perl: today scripting languages like Python, JavaScript are getting closer to Java or ML with compile-time type checkers and sophisticated type systems. Few new or existing languages are getting similar to Perl.

I don't think Perl 6 had anything to do with it. I wrote a lot of Perl5 in college, and didn't particularly want to write any more Perl5, or adopt Perl6.