What good reason is that?
1. CPAN was great 20 years ago, but it's a joke compared to modern dependency management systems.
2. Functions don't have explicit parameters, and still shift off of @_. (This can be kind of a catch-all for all the "things that are useful for scripts, but suck for programming in the large" design decisions in Perl 5, because I honestly don't remember all of them at this point.)
To this day, I've seen package management systems for many languages, and none I've seen has been as good as CPAN in terms of
(1) Consistent place for distribution + documentation (cpan.org/metacpan.org)
(2) Automated testing on a wide variety of platform and configuration (cpantesters.org)
(3) CPAN has as standard for declaring dependencies in packages, but a newer "cpanfile" may be more akin go "modern" dependency management. Perl has also had a way of 'use Package $version' right in the source code for ages.
(4) the command "cpanm Package::Name" (or even the older "cpan Package::Name") almost always results in figuring out whatever distribution needs to be installed, even if the distribution is named differently from the package name.
I worked with Perl daily and find CPAN even more of a wasteland than NPM. The average package there hasn’t been updated in a decade and has ancient dependencies to match; takes months / years for clients to be written for new tech.
Languages like perl--like common lisp, and c--are Stable. They change, some, but you can count on old code working. If a 10-year-old package Works, what reason is there to update it? I wrote a c library which has seen no updates in about 2 years--because it doesn't need them. It already does everything I need it to do.
Often I'll just not find the library I want since nobody using that tech is actually writing Perl. For example, complete lack of a working GraphQL package until late 2017.
CPAN search in particular is unbelievably bad. The first result for 'Postgres' is a package last updated in 1998 (not joking), try to find a usable driver here: https://metacpan.org/search?q=postgres. Even the widely used DBI package has last seen an update almost a year ago.
As for DBI, it's definitely in the "stable" category and isn't trying to keep up with anything; the DBD::Pg driver though was last updated this month.
Isn't Perl 6 already backwards incompatible?
> module names are both filesystem lookups and package stash lookups
>> names converted to lowercase internally
Converting names to lowercase internally fixes this.
> it's entirely possible for valid programs to use two modules that only differ in case
Many people (myself included) would see this as a mis-feature not worth saving.
Modern dependency management systems (at least for language-specific packages) still don't hold a candle to CPAN, IMO. The namespace structure alone is something that's sorely lacking in pretty much every other language-specific package system. I'm glad Perl6 is (finally) gravitating back in that direction (though the prior system of "let's just pull from a bunch of GitHub repos" was still better than 91% of other languages' dependency/package/library/module/plugin/etc. installation approaches, or at least so I felt, having used a lot of such languages).
> Functions don't have explicit parameters, and still shift off of @_
I don't see anything fundamentally wrong with this. It's different from other languages, but not necessarily bad (again: IMO). It makes it easier to reason about things like varargs without needing special syntax for it.
The class system is similarly deconstructed (i.e. you explicitly "bless" arbitrary data structures instead of relying on the language to automagically do something behind the scenes), and I appreciate that explicitness.
---
Like, I find it kinda interesting that the two things you cited as "bad" are also two things I very strongly like about Perl. Different strokes for different folks, I guess.
How so? I use npm/yarn daily and think they are mostly giant insecure playgrounds for teenagers with too much time on their hands. Browsing through node_modules on a large project is enough to make you give up software development and take up heavy drinking. Half the code I see in node_modules wouldn't pass a PR review at my own company. Yet we still depend on it daily.
> 2. Functions don't have explicit parameters, and still shift off of @_.
Never been a problem in my experience. The expected arguments are generally at the top of the sub. You must really not like functional programming then, with heavy use of curried functions and whatnot.
The bigger problem is with passing around an %options hash, and this is true of JavaScript as well, is that the keys can be easily mistyped leading to bugs. Not even TypeScript fixes this (because developers are generally horrible about defining types, which have to be defined perfectly).
2. Whether you go positional or use an options hash, you still need to carefully unpack your args at the top of the subroutine. And do it consistently. There are a ton of libraries to help with this, too.
The most important thing is to pick a house style and do it everywhere that doesn't need to be different.
Why? References are not scary and they work just like in any other language -- they are simply a memory address that points to another value stored somewhere else.
my @a = (
{ first=>1, second=>"b", another_ref=>["y"] },
{ first=>1, second=>"b", another_ref=>["z"] },
);
say $a[0]{first}; # Outputs 1
say $a[1]{another_ref}[0]; # Outputs z
my $a2 = \@a; # top level is a reference too now
say $a2->[1]{another_ref}[0]; # Outputs 1, arrow only needed at top level
# The following are alternate syntax that I find unnecessary and better left alone (and most do)
say $a2->[1]->{another_ref}->[0]; # Outputs 1, explicit, entirely unneeded because it's unambiguous without extra arrows
say $$a2[1]{another_ref}[0]; # Outputs 1, extra prefixing $ dereferences first level ref
Personally, I like that it forces you to be aware that this data structure is likely in use somewhere else as well, and your changes may not be local (which is true of deeper levels regardless).