What should be core in Perl 5.16?
What are the Perl modules you immediately install when you get a new Perl? Jesse Vincent, the Perl 5 pumpking, opened the door, albeit slightly, to possibly considering maybe thinking about provisionally expanding the Standard Library. Is that modally weak enough for you? (Jesse tells me I misread him, so, maybe the door is not open and never was).
Larry designed Perl 5 to be extensible, which is another way of saying that he designed basic Perl 5 to be small. CPAN is great, but we also know that through various social and technical factors, mere mortals struggle with the idea of having to get their wheels, fenders, and mirrors separately once they buy a car. Distributions such as ActivePerl and Strawberry and popular partly because they come with the extra bits. Non-perl people with their fingers in the pie tend to think about those included parts differently than the "third-party" parts.
Now, the trick is that many tasks have their own sets of modules. There is some overlap, but I bet that many areas have modules that only they use. Aristotle said somewhere recently (probably in comment) that there are at least five major application areas for Perl and that they have different needs and goals. Core Perl should try its best to satisfy everyone (although that doesn't mean it actually needs to satisfy everyone).
You also have to consider that ever addition to core is another task on the maintainers to-do list. Recently, p5p have made great advances in managing dual-lived modules, but that still doesn't mean it's painless. Also, anything dual-lived needs its prereqs to be dual-lived. That can be a huge amount of extra work piled on a numerically-stable group of workers, as well as tickle down effects to dual-lived module maintainers. However, that shouldn't prevent us from at least daydreaming.
I have my own set that I immediately install because they relate to the work I do, which is a lot of data discovery and organization. Just because I immediately install them doesn't imply I think they should be in core. If most people immediately install them, that's a different story:
- DBI with the mysql, postgres, and sqlite drivers.
- LWP
- JSON modules
- XML::*, especially XML::Twig
- HTML::Parser and various subclasses
- WWW::Mechanize
- YAML::*
There are other things I don't use but I know will make Standard Perl much more useful:
- Class::MOP - there is noise about making MOP part of "built-in" Perl. A boy can dream, after all.
- cpanminus - people like it and it solves most people's needs.
I'll update this list as I think about it more.
I'm the author of Mastering Perl, and the co-author of Learning Perl (6th Edition), Intermediate Perl, Programming Perl (4th Edition) and Effective Perl Programming (2nd Edition).
I'd put in a vote for Config::Any and the various Config::* it supports, though I'll admit that's a gut-reactio and I haven't really thought it through.
"Aristotle said somewhere recently..."
I had this handy, if anyone is curious: http://www.nntp.perl.org/group/perl.perl5.porters/2011/02/msg169141.html
The first thing I install is Task::BeLike::hanekomu, so I'd vote for anything that's in there. :)
I thought about having people upload their own Task::BeLike modules, but then that restricts it to people with PAUSE accounts, a numerically-insignificant slice of the Perl community.
Having said that, I should make one anyway. I've been thinking about a program that could automatically create it for people if they point it at their Perl application directory.
Of the stuff I have installed LWP is probably the most useful, followed by Inline and DBI.
It wouldn't be too far from CPAN.pm and CPANPLUS's autobundles to an auto-BeLike creator.
Getting back to the topic, here are my votes for core:
For serialization JSON/JSON::XS, YAML::Tiny
For networking: LWP (or similar)
For toolchain: local::lib, Test::Most, App::cpanminus, Perl::Critic, Perl::Tidy
For language extensions (that should be no extension but actually part of the language): Try::Tiny or similar,
Moose (and some often used mooseX stuff)
I really love to see Moose being in core. Having a sane advanced object system in the core sure helps it being adopted.
Concerning base language constructs/serialization/toolchain I really love bloat and not having to choose from CPAN (you still can).
Definitely any HTTP client.
App::cpanminus
Try::Tiny
JSON::XS
YAML::XS
DBI
DBD::SQLite
HTTP::Tiny
Perl::Critic
Perl::Tidy
You get your wish with HTTP::Tiny in Perl 5.14. :)
App::cpanminus
DBI
DBD::SQLite
JSON::XS
LWP
Moose
perl5i
Plack
TryCatch
Set::Scalar/Object
List::MoreUtils
(voting for what others have said)
Inline
JSON
List::MoreUtils
DBI and DBD for mysql, sqlite and postgres
LWP (or at least HTTP::Tiny)
Try::Tiny
local::lib
perlbrew
Moose (I'd love to see it in core, but I understand those that have concerns about it's deps too. So the best of both worlds is to make the MOP core :)
(stuff I haven't seen anyone else mention)
DateTime
Time::Clock
Math::BigInt
Parallel::ForkManager
Params::Validate
Sub::Exporter
Unicode::Normalize
URI
Math::BigInt has always been in the Perl 5 core, and Unicode::Normalize has been in core since Perl 5.8, so you immediately get two of your wishes. :)
One quality of modules that makes them useful to be in the core is if they have an XS component.
For me, I use modules that depend on HTML::Parser frequently.
For example, cPanel has a nice tool that allows shared-hosting customers to automatically install private copies of Perl modules and their dependencies. I believe however that the system does now allow these users to access a C compiler, so various popular module installations fail.
About the only module that I might even consider adding to core that hasn't already been mentioned is:
Log::Log4perl
But I would could it more of a second round choice.
It would be nice to have some OO framework in core but Moose is really big.
Good question though.
JSON and HTTP::Tiny will be added in 5.14.
local::lib
DBD::sqlite - adding DBD::sqlite will allow moving to distributing sqlite-based CPAN index. And it would be at least one DB in core.
Archive::Zip
Mouse (it is already in core, but as submodule of Test::More)
File::Which
PAR (or at least client part of it)
Win32::Console
Win32::Job
win32 registry manipulation module
Is it JSON or JSON::PP? Meaning in your code, will you be able to just use JSON? My understanding was that it was JSON::PP only.
If you're going for an everything-and-the-kitchen-sink core, look at what Strawberry Perl includes. It already comes with lots of useful modules that are (or were) difficult to build on Windows, like DBD::SQLite, XML::LibXML and XML::Parser.
Of course, by bloating the core, you heap maintenance burden upon maintenance burden. But maybe you can create a cross-platform distribution of something like Strawberry Perl, not unlike what ActiveState already provides for HP-UX and other unixish OSes.
No one has mentioned Sub::Name so far, or perhaps there is a way to do the same with core-perl already that I am not aware of?
Subroutine signatures ... and perhaps multi methods ;)
I find File::Util really useful, and would make sense if it was added to core.
Moose would be also great.
I'll second the nomination for:
# App::cpanminus
# Perl::Critic
# Perl::Tidy
# Test::Most
# Text::Template
# Try::Tiny
And of course shameless plug--- all of the Chess::PGN modules :)
As a Perl::Critic developer, OMG no for core.
* I have no desire for the hell of a dual-lived module maintainer
* Can you imagine the fights over what the default settings for it would be? It would make the current OO discussions look tame. The flames would be visible from miles away.
I don't want additional modules, I want language changes. (Obviously would need to be controlled by feature.pm.)
*
classandmethodkeywords.* warnings on by default.
* The equivalent of autodie built-in.
* The equivalents of Try::Tiny and Capture::Tiny built-in.
* The equivalents of List::Util and List::MoreUtils built-in.
Also, kick CGI.pm out of core (plus a bunch of the other non-language things). (This is obviously fantasy-land stuff here.)
I rescind my previous vote and second Elliot's votes.
A degree of restraint coupled with some changes that would have a systemic improvement to the OO in Perl.
With the removal of CGI.pm it would focus the core of language specific (and tool chain specific) needs.
Maybe more can be done to promote Modern::Perl, perl5i and Task::Kensho?
Modern::Perl is the least "invasive" in it's changes.
perl5i amps it up a bit.
Task::Kensho really goes all out and now is large enough to break out into separate sub-groups that are more or less task focused.
Yes, Yes, YES. I agree 100-freakin' percent.
I might also add that I *completely* agree with your last bit about CGI.pm et. al. In my perfect world (aka. if I were (pump)king) the decision would more or less go like this...
"If it's not there to either extend or improve the language, and it's not there to make it easier to install from the CPAN (local::lib, woo-hoo!) or it's not absolutely necessary for other ease-of-use for things like building, testing, reading docs, etc... DEPRECATE AND REMOVE."
Interesting that you mention List::(?:Util|MoreUtils) - I use those so often and automatically that I sometimes forget they're *not* core already!
As a startup about to release a service in two weeks, about 90 percent of our infrastructure is Perl. I was hoping to offer user client agents in Perl but can't because of the lack of LWP/HTTP client and SSL in core Perl. So the agents we are using are written in
...Ruby and Python!
It kills me but I have to make it as simple as possible for customers.
So my principal request for the core:
LWP/HTTP client
SSL(Crypt-SSLeay) - for HTTPS
Socket6/IPv6 - Already have customers asking for this support.
My list of "would be nice too" for the core:
JSON
DBI(at least support SQLITe - DBD::sqlite)
perlbrew
cpanminus
I fully support this list, Elliot!
This really shouldn't be a popularity contest for a set of recommended modules.
Modules should have a clear reason to be in core. eg, they provide common functionality that CPAN modules should be standardizing on. They should be fixing core language deficiencies. Or because they implement a new important language feature people want but don't want if it's not in core (eg, autobox, Coro).
I think the list should be whittled down to only a few modules which fall under the "papering over really bad parts of Perl" category;
* Class::MOP as I mentioned on-list
* Sub::Name
...
Basically there are a lot of modules in the dependency chain of distributions out there like Plack, Catalyst and Moose - these should be looked at to see whether there are some there which should really be in Perl core, as a language feature.
But it needs to happen slowly, one by one!
I vote for
local::lib
App::cpanminus
(so that one can easily extend one's install).
Also not mentioned otherwise
Sub::Exporter
Dir::Self
There seems to be roughly 2 categories here:
- people who use Perl primarily on their system(s), or at least on systems they have control over. Those people want a minimal Perl, and a way to install extra modules, CPAN(PLUS|MINUS)?. Anything else restricts their choices and brings them no clear benefit, since all modules are just one command invocation away,
- people who deploy apps on systems they don't control, whether it's on a hosted system or on customers machines. Those would greatly benefit from an expanded Perl core as they have to restrain their environment to what's likely to be available on an unknown system.
I think Max and Mark (how's that for a band name?) above give us an interesting base though: an extended core that would include network modules (LWP), common XS modules (because you can't assume a C compiler, DBD::*, why stop at SQLite?, XML::Parser, XML::LibXML, Text::CSV_XS, probably some image manipulation module) local::lib and CPAN (already in the core) should do. Then applications can install extra modules locally (of course that only works for systems that have network access either to the outside world or to a local repository)
Come to think about it isn't this very similar to Strawberry Perl? Then make Strawberry Perl the base for the new extended Perl core, et voilà!
I wonder what good will class & method do if they are just synonyms :p
I'd like to see function signatures. Not the current hacks/code injections, but a clean built-in feature
DBD::SQLite is the only DBD that does not need external libraries. All other DBDs ship without the client libraries and need other components like `libmysql` or Oracle client libraries. And those other components usually cannot be distributed with the DBDs themselves due to licensing issues.
For core, I think we should really concentrate on the stuff that is hurting Perl:
- OO. The boilerplate and the verbosity needed to write OO with bless feels not really Perl.
=> Moose.
- Exception handling.
=> Try::Tiny
- Threading
=> ???
C.
I too agree with Elliot: let's not add too much to the core that isn't really close to the language. I'd like a MOP and better exception handling, but other than that we don't really need to add anything.
My knee-jerk reaction is "no more stuff in the core!" Core Perl 5 is already getting bloated to the point *nix distributors are considering removing it from default installs. But after reading over others' comments, I do think there are a few additions that merit discussion. Most importantly, adding some form of try/catch block ala Try::Tiny should be discussed, especially if it could be augmented by a basic exception class like Exception::Simple. The eval exception handling syntax is just too crufty and awkward to use. Just about all modern languages have some type of built-in exception handling, and none of them have syntax as difficult as Perl 5's.
Ctypes!
There are a large number of tools I'd like to use that have C client libraries and since my C is weak and my XS is weaker having ctypes in core would be quite awesome.
http://gitorious.org/perl-ctypes/perl-ctypes
But I would happily settle for it to be on CPAN.
PS Thank you Reini Urban for picking up and running with the project.
Ctypes is great in that it doesn't need a compiler, but using mutant pack codes for function prototypes seems like a bad idea. I would rather see something that parsed (a subset of) C function prototypes. Even more awesome would be something that demangled and parsed C++ function names to get the prototypes automatically.