Unfortunately most of that doesn't really matter for any non-trivial project, because you'll almost unavoidably need a module for something. A lot of the time you'll find out that it's bit rotted 5 years ago, and the bug tracker has a 7 year old issue nobody seems to have read.

It's even worse for anything that interacts with libraries or APIs -- those change over time, and often nobody does the work to repair compatibility.

So I think at this point it's fair to say it's dead. Even if the core language is technically functional, the ecosystem is rotting.

Perl doesn't need an ecosystem any more than the Almquist shell does. It's just a nice tool that's omnipresent on UNIX systems. It's definitely going to be useful for shell scripters for a very long time.

list of perl modules in cpan sorted by last update time

http://www.cpan.org/modules/01modules.mtime.html

My 5 years and counting project diagrees with you.

> because Perl has not introduced breaking changes since 5.000.

I was curious and you made me check. There's a number of releases with incompatible changes listed if you google for it. For example a whole list at https://perldoc.perl.org/5.12.0/perldelta#Other-potentially-... So no, there's been quite a few.

> no, there's been quite a few.

Yes, most of them relatively minor though, which is why the OP has never stumbled across one.

(I found one once-- it turned out one coder had invented his own hash slice syntax. It wasn't supposed to work, but it did, until a particular upgrade...).

In general, Perl has been traditionally committed to backwards compatibility, but not fanatically so-- there is a deprecation cycle that can be used to remove the more problematic things.

Yes, and these changes are feature flagged and optional and would not affect existing scripts.

No, those are "real" breaking changes in that a script running in one version of the interpreter could break if it runs in a later version, without any modifications to the script itself. But in fairness, they're a very conservative definition of breaking changes - e.g. the output of the `--version` flag changing, or some Unicode characters classes changing.

I found Perl suffered from dependency issues as well. Not the language but the modules you tend to want to use. Especially when they're underpinned by c libraries. I'd preference operating system libraries then fall back to Cpan. Over time it got harder to maintain older applications as the libraries dropped out of repositories. Have you found anything similar?

You're right, and this is why I don't use third-party modules. If I need something I can't write myself, I use the shell version instead of a module.

Seems like you're jumping through a like of hoops to write thing in a Java-like fashion when you could be using Java, which has a much healthier ecosystem.

Java has many other shortcomings which keep me from using it.

python also has this problem