Fat Versus Thin Core
I used to feel the Perl core should be as small as possible. That is, it should ship with the smallest number of modules whilst still being "practical". For everything else, there is CPAN.
So naturally, I was pretty pleased when I heard that CGI and some other modules were going to be removed from the core in perl 5.20. But lately, I've started to change my view on that. Here is why...
I've been watching the p5 porters for a couple years, and I feel that major enhancements to the language just aren't going to happen. There are lots of different reasons for that -- some technical, some social. I'm not bitter and I'm not pointing the finger. This is just what happens when programming languages and their communities mature. The same will happen to Ruby and Python.
But I know that Perl still has a very long and prosperous life ahead of it. But if the future does not lie in the language itself, then where does it lie? I think the answer might be the modules it ships with.
Perl owes some of its success to the fact that CGI.pm was right there in the core at a time when lots of people were starting to do dynamic web sites. Here we are 20 years later, and CGI-style progamming has been replaced by frameworks with routers and templates and controllers. It makes sense to remove CGI.pm from core now, but perhaps we should also be looking to put something in its place. And we have plenty of things to choose from: Catalyst, Dancer, Mason, Mojolicious. How we pick one is a whole other story. But I contend that shipping one of them in the Perl core could be path to the future [1].
I understand that a fatter core presents a maintenance burden for p5p. But these frameworks actually have pretty large and vibrant communities. Most are probably bigger that p5p itself. So putting one of them into core could help bring many new contributors into the p5p sphere. Some of them might even make significant contributions to the language while they are there.
To put it another way, some folks call Ruby a language with "batteries included". At one time, Perl was the "batteries included" language too, because it had regexes, and interfaces to common system calls, and *gasp* CGI.pm. But now, the world has caught up and we expect more from our languages.
So maybe we need to think about what kind of stuff people want to do with computers these days, and then focus on providing them with a Perl offers them a way to do it. Perl doesn't have to be all things to all people, but it ought to make a strong effort to appeal to some group of people. That probably means putting more modules in the core, rather than less.
[1] The same thinking could potentially be applied toward DBIx::Class or Poe, or some of the other widely used frameworks.
Hacker, speaker, author, dad.
Anyone is free to package up their own "batteries included" Perl distribution (or Task:: cpan list) so there is little reason for those with the most scare skills and limited time to do so.
That's especially true since local::lib and perlbrew and cpanm make it easy to have compartmentalized installations of Perl.
If anything, my $WORK-related desire would be to have an easy way to what local::lib/perlbrew/cpanm do except with relocated RPMs to hand off to the server administrators.
> Anyone is free to package up their own "batteries included" Perl
True, it is easier than ever to do that sort of thing. Gabor Szabo's DWIM Perls are a great example of that. But that is just not the same. "Batteries included" really means included in the official release (the "pumpkin perl", if you like).
Perhaps this has changed, but the last time I looked, local::lib and cpanm are not mentioned in the Camel book nor the standard perldoc. As wonderful as they are, utilizing those tools requires additional tribal knowledge and effort, and that doesn't help make the language more appealing to newcomers.
BTW, the "batteries included" phrase was first popularized by the Python community, methinks.
The proper replacement for CGI.pm is Plack, not a framework as Catalyst, Dancer, Mason, Mojolicious etc.
Yes, very good point. Perhaps we should provide both the server glue (Plack) *and* one of the web frameworks. Why not ship a fully functional web application stack?
That's certainly not the only thing that Perl is used for. But at least it is a well defined, large, and growing audience that we could target.
I'd argue that choosing one of the web frameworks would immediately invalidate all others. CGI.pm is an interface, not a framework. PSGI is an interface, Plack is what implements it (maybe even too richly).
The people who choose not to use CPAN are still out there, and giving them a web framework would give them more reason to not use CPAN. That web framework would then have the "blessing" of the p5p. It would become "the official Perl Web Framework", which I believe would be harmful to the CPAN ecosystem.
That said, there are plenty of other things that could become core modules that would be of great benefit to the greatest number of Perl programmers without stifling competition (local::lib, for example, has no competition that I know of).
Which Linux distro is the standard now? They all use more-or-less the same kernel, but there's no agreement on what else to include, and this situation has stayed the same for years. The choice of a "standard" is really complex, and no particular version has won. Had Linus chosen a particular package manager, graphical toolkit, and window manager back in the day, Linux might have a single "batteries-included" version (or it might be dead).
It's too late for Perl to do that now, since too many people are too heavily invested. It's a frustrating conclusion, but I think so-and-so's versions of Perl will just have to coexist until one wins, or they all fade.
I disagree. Picking a module for inclusion in core will not "invalidate" similar modules. It does signal a preference, but does not inhibit other modules from competing. This isn't about being "fair" anyway. This is about being strategic.
Besides, there are plenty of CPAN modules that have similar functionality to core modules. Nothing has stopped them from flourishing. 20 years from now when there's a better kind of server glue, we can take out Plack and put that in. That is what progress looks like.
As you said, this will have no impact on non-CPAN users -- those people will not be changed. But it will impact the next generation of programmers looking for a language to get things done quickly and easily. At one time, you and I were those programmers, and Perl served us very well. But we seem to have forgotten our roots.
The analog to Linux distros is interesting. But the ecosystems seem to be different in nature, or at least in scale.
To my knowledge, Strawberry Perl and ActivePerl are the only "other" Perls that have much traction. And that's because they fill a very specific gap (Windows).
Unlike Linux, I'm not sure the market for Perl is deep enough to really support a lot of competing flavors. Which leads me to think we should leverage the primary flavor as much as we can.
local::lib and cpanm are mentioned in Learning Perl, though.
I was thinking more of perl5i, DWIMperl, Task::Kensho, Modern::Perl, and all the other stuff that tries to be a base installation or tweak defaults (there are probably others). AFAICT they're all vanity projects, not having even achieved the status of the competing Linux distros, collectively installed by the majority of Linux users.
I agree, but the politics of forcing a single flavor would be incredibly ugly and destructive, since there isn't anything close to a community consensus. Then again, maybe a brazen "f-u" to a bunch of projects would force some maintainers to create real Perl distros. If Catalyst and its dependency hell, or Mojolicious and its NIH philosophy (tongue-in-cheek in both cases) were made the default, there would be forks.
I think the premise of downloading a thin core and then an extended core is quite solid. I've come across two examples recently where other programs do this.
I was working on a fresh Ubuntu installation and I couldn't get the Vim syntax highlighting to work. I went to the sys admin and asked him to download the full version of Vim. He knew immediately what I meant and once he had done it I had all the vim features I needed. I didn't have to keep going back.
Later, on the same installation, I couldn't get our Perl modules to install because there wasn't a C compiler. Once I nudged the system administrator, he downloaded a development package and I had all the tools I needed. I didn't need to keep going back for a compiler, for make, etc, etc.
If we go for a thin core, most people are going to want one of the extended cores as well. There might be an extended core for web development, for GUI development, for bio-informatics, for systems administration and so on.
We don't have anything like that. There have been plenty of attempts, but none have caught on.
I think one of the reasons is that they try to specify a single solution. For example Task::Kensho specifies Catalyst. There might be more chance of getting a consensus if it allowed three or four frameworks. Why not Catalyst, Mojo and Dancer?
The idea that "There Is More Than One Way To Do It" has some merit as long as it's not taken to an extreme.
Three or four frameworks? Fine. Thirty or forty? No. Three or four accessor modules? No worries. One hundred and twenty? No.
Python has WSGI and Django and Ruby has Rack and Rails, and none of them are shipped with the language core.
I would prefer a thin Perl core, but not until we can install modules without super-user permissions on any system and having them recognised immediately by perl.
The path to this nirvana-like place is not that hard:
1. settle on ~/.perl5/local [1] as your own personal "local::lib" source;
2. make sure perl always sources /etc/perl5_policy.pl first: this should take precedence even over sitecustomize.pl which is a per-library file;
3. distribute a default perl5_policy.pl file that, if running as a non-priviledged user, and if ~/.perl/local exists, prepends the ~/.perl5/local/lib and the respective archname libdir to @INC, and adds ~/.perl5/local/bin to PATH ENV.
4. make sure cpan and cpanm clients default to ~/.perl5/local when they run as a non-priviledge user. Ideally they would get this information from perl5_policy.pl somehow... Maybe perl5_policy.pl should set ENV PERL5_LOCAL_LIB if there is one and if he updated @INC.
After you have the workflow in place that allows anybody to install modules without fuss, then you can make the Perl core thinner. Until then, you would be shooting yourself in the foot. The biggest obstacle I see around me when the Perl subject comes up is with installing modules. It's not as easy as it could be.
[1]: there was a module that would give you the proper place where per-user config files should be placed, can't remember the name, but use that;