The worry with any language dying is the loss of knowledge that accompanies its demise. CPAN has a lot of great libraries that once used to power the early internet. Decades ago, it was in a Perl group / forum that I first heard the term "do not re-invent the wheel" when someone enquired about making some kind of their own CGI framework along with a great write-up about all the unique edge cases that the existing library already handled due to the experiential knowledge it had gained during its development. These were also the times when Oracle DBAs used to love Perl.
back
2 comments
CPAN was pretty great, all the good practices around documentation and unit testing as well as quite possibly the first real internet native shared library community complete with beautiful tooling for one step download/install/test and strict curation.
on my first day of my first software internship in the mid 90s, my boss handed me the ora programming perl 5 book and said "read this." it served me well as a swiss army knife for many years.
Unfortunately, "do not reinvent the wheel" coupled with "there is more than one way to do it" leads to a proliferation of wheels that you pull in in any medium-to-large project.
There are many ways to have OOP? Moose, Mouse, Moo, MooseX::Declare, Class::Accessor — you are pretty much guaranteed to pull in them all and have them coexist in runtime. Now Corinna or whassname is coming in, but it has no users yet so it doesn't count. JSON? You're guaranteed to have both JSON::XS and CPanel::JSON::XS. The list just goes on and on. HTTP clients? You have Furl, LWP::UserAgent, something built atop IO::Socket. TLS with HTTP? LWP::UserAgent::SSL, IO::Socket::SSL, and someone will use Net::SSLeay raw just to watch the world burn. You pull in all of the latter ones courtesy of modules doing API integrations because their authors just have their favorites.
Web? Oh, you want to do web. Mojolicious, Dancer, CGI::Application, just CGI.pm... Granted, at least you won't have libraries pull those in willy-nilly, thank goodness.
>There are many ways to have OOP? Moose, Mouse, Moo, MooseX::Declare, Class::Accessor — you are pretty much guaranteed to pull in them all and have them coexist in runtime.
I think this is hyperbole. Generally, you won't be mixing Class::Accessor and Mo* based dependencies unless you are dealing with a shitty, barely maintained legacy codebase.
There was a progression to things, mostly because of performance reasons why there is a bit of a proliferation. Moose (and the underlying Class::MOP) were about providing a meta-object protocol for Perl which didn't exist before it. As such, it was focused on being correct over fast. A whole community sprang up from stevan's art. Then sartak's Mouse came along and made some performance improvements with some compatibility caveats. Finally, mst's Moo stripped away the "reflection" aspects of Moose to really squeak out even more performance.
MooseX::Declare was always a (beautiful) research project. I spent some time in that space welding POE and MooseX::Declare together. But these weren't suitable for any kind of production code. If you see this live somewhere, you should definitely rip it out lol.
As for TIMTOWTDI, this is sorta why project Andy Lester's Phalanx came about (it was trying to bless a chunk of modules as a sort of smoke test for Ponie (perl5 implementation on the Parrot VM (which was the first step toward a Perl 6, now Raku)). It was trying to provide an opinionated set of high quality libs for SWE.
Unfortunately, working in Perl really requires a bunch of skill and discipline if you want a long-term maintainable project. This means really looking at your dependency tree and making difficult decisions on which libs to use specifically to avoid installing all of CPAN. npm's installing the world behavior was foretold by Perl.
> I think this is hyperbole.
(Looks at the dependency graph) No, it’s a fact.
> Generally, you won't be mixing Class::Accessor and Mo* based dependencies unless you are dealing with a shitty, barely maintained legacy codebase.
I don’t. But the modules my project depends on (transitively) do, because those modules were developed and last touched during different fad eras. So when the app starts, I have, like, four OO systems, three ways to do JSON, two to do YAML, and four ways to do HTTP in the memory.
Also, the authors of said modules tend to have Egos and Opinions (capitalization intended) that prevent them from converging on common things.
... and now you have Mojo::Base which is kind of like Moo lite with batteries included. Last week I was concurrently programming some Mojo::Base stuff and some python stuff with cached properties, and I way more enjoyed the salience of my intention in the perl code.
No difference to Python dependencies nowadays.
Not really. There is typically just one import for CSV, JSON...etc. It can be hell to get the various libraries to work though.