Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl Monk, Perl Meditation
 
PerlMonks  

Re: What modules should be added to the corelist?

by Anonymous Monk
on Aug 16, 2019 at 14:25 UTC ( #11104571=note: print w/replies, xml ) Need Help??


in reply to What modules should be added to the corelist?

That's the problem with the core list. It implicitly becomes a "recommended" list and recommendations change. But I also think we've gone too far in the opposite direction. Path::Tiny is better than IO::All, and Path::Iterator::Rule is better than File::Find. I think your debugging choices and FFI::Platypus would certainly be good candidates though.
  • Comment on Re: What modules should be added to the corelist?

Replies are listed 'Best First'.
Re^2: What modules should be added to the corelist?
by Corion (Pope) on Aug 16, 2019 at 14:33 UTC

    Actually no. corelist is a frontend for Module::CoreList, which only describes "what modules shipped with versions of perl".

    Since some time, the Perl developers have decided to only include in the Perl core distribution whatever is necessary to build and install Perl and to install modules from CPAN.

    You are still free to create richer Perl distributions, as for example the good folks at http://strawberryperl.com/ and https://activestate.com have done. Alternatively, you can also simply create a Task:: module that lists your favourite modules.

    To expect that the Perl developers care for and maintain a module that you consider good is expecting a bit too much. CPAN is available and as you already understand, recommendations change. Hence this is why the Perl core aims to only include what is needed for/by Perl itself.

    For what SawyerX aims, maybe see his keynote at Perlcon in Riga - he wants to include a Moo* class constructor/accessor builder in the core. Maybe you can lobby for your other trends du jour there.

      Since some time, the Perl developers have decided to only include in the Perl core distribution whatever is necessary to build and install Perl and to install modules from CPAN.

      That's right, but goodies got added which aren't strictly necessary for those purposes, e.g. Hash::Util::FieldHash. I'm glad it is there (though I liked more the name choices of Alter from which it derives).

      perl -le'print map{pack c,($-++?1:13)+ord}split//,ESEL'
      To expect that the Perl developers care for and maintain a module that you consider good is expecting a bit too much. CPAN is available and as you already understand, recommendations change. Hence this is why the Perl core aims to only include what is needed for/by Perl itself.

      While agreeing with the lean core principle, I've seen Perl get severely eclipsed TWICE by completely inferior languages that sell themselves as a "kitchen sink" and as having "batteries included". This is about what people want and what Perl needs, not my favorite modules.

      Clearly Perl is incomplete without modules or the corelist would not have over 600 items. The only question is what to include. My suggestions fall into 3 broad categories:

      1. Complete Perl by bundling missing features (like a REPL)*
      2. Update old interfaces and make things easier (like IO and Rule)
      3. Encourage Perl use by using other languages in Perl! (FFI, Inline)

      I would settle for Path::Tiny but this example from IO::All says it all:

      replace this: open STUFF, '<', './mystuff' or die "Can't open './mystuff' for input:\n$!"; local $/; my $stuff = <STUFF>; close STUFF; with this: my $stuff < io './mystuff';
      * Frankly I would go wild with things like PPI, Perl::Tidy, Perl::Critic, Perl::Examples, something like Classic::Perl (expanded, for complete backcompat), B::Keywords, B::C, B::CC, Modern::Perl, etc.

        Yes, and there is nothing stopping you from doing this, as I already outlined. Your idea of what is important is entirely not my idea of what is important. "Updating old interfaces" means breaking backwards compatibility and old scripts - feel free to do that, but don't call it Perl.

        To expect that such modules would be maintained by the Perl maintainers is too much.

        IO::All is a horrible idea that opens up the locker of footguns that PHP closed a long time ago, by allowing open("http://..."). It would be a very bad idea to include it in the Perl core.

        Also look at Python, whose Batteries Are Leaking. Having modules maintained separately from the core is important because the module release cycle is different from the Perl core release cycle.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://11104571]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others taking refuge in the Monastery: (5)
As of 2019-10-19 16:05 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    Notices?