Dance with the one that brung ya
I just read chris fedde's response to Ejecting CGI.pm From the Perl Core, my head nodded in agreement from start to finish. It helped me clarify a few of the thoughts and concerns I've had bouncing around in my head for the past several days.
So here goes: I think it would be a mistake for perl core to not "Dance with the one that brung ya".
How many of us are using Perl because of CGI.pm? When I first got my feet wet with programming it was for the web, using Perl. It was a good month before I got a feel for where perl ended and CGI.pm began. At first they were very much one in the same.
I realize times have changed (tho the title might hint otherwise) I found Mojolicious and haven't looked back. I get a sense that some elite and enlightened (not a dig at EPO) group of "thought leaders" in the community have moved on too. Good for them. I work side-by-side with many, many programmers, sysadmins, and general technologists, that fall back on apache/CGI.pm because they just know it works, and know it's available to them now in their environment. These people may or may never see that distinction between Perl and CGI.pm.
Until we have another de facto[1] standard in place, I say we leave CGI.pm in core. Until that de facto standard is as widely publicized and adopted, I say we leave CGI.pm in the core. It can be a confusing landscape for someone starting out in web programming today. Is abandoning the weekend CGI.pm hacker, and losing them to other languages and frameworks worth the benefits associated to releasing a utopian CGI.pm-free Perl?
How many of those weekend hackers will eventually fall in love with modern perl web frameworks after dabbling under CGI.pm for a while?
I'd bet that far fewer of these weekend/day-job hackers just trying to get a job done will have the opportunity to find and adopt existing modern frameworks if they fail straight out of the gate due to a module or two missing from core. When their expected page doesn't load they'll scratch their heads, then turn to google for how to set up a web site in python or ruby. Besides, they'll think, it's time I looked at something new anyways. Let's hope for their sakes they're lead down another path because a google search for building a web page with perl will be in vein, or frustratingly difficult on a modern perl without CGI.pm in the core.
Will Willis (silent11)
Regarding "de facto", I think CGI.pm is the victim here, it grew to a de facto standard within a TMTOWTDI language and culture. Though it wasn't the language or our culture that promoted CGI.pm to this status, I think it was done largely from the book shelves.
Are you suggesting that people new to Perl will actively seek out and install Perl 5.20 (the first release where this will plausibly happen), discover that CGI.pm is no longer a core module, decide that it's too much work to install from the CPAN or a package manager and will instead switch to Ruby or Python where they have to download and install Django, Rails, Flask, or Sinatra, because that's somehow easier?
> Is abandoning the weekend CGI.pm hacker, and losing them to other languages and frameworks worth the benefits associated to releasing a utopian CGI.pm-free Perl?
Let me counter. By leaving in hard to use modules in a place likely to be used by newcomers, don't we risk losing people who might be excellent Mojolicious or Dancer hackers to Tornado or Sinatra when the framework they try cannot do all the modern things they want? CGI is bad and shouldn't be shown to newcomers, and worse for them if they find it unsupervised.
When people talk about Perl they think 1996 and we cringe. However, you suggest that we ought to let newcomers learn like its 1996. Systems like Mojolicious::Lite are a much better bridge to web programming. If they find CGI.pm they may never find their way to M::L and then exit for something better in another language. This is far far worse than the scenario you envision.
@Joel, I'd love it if M::L were front and center in the newcomer's face. But how do we make it so obvious to newcomers that they think of M::L when their boss says they have till the end of the week to come up with a "CGI" script that does XYZ.
I'm all for moving CGI.pm out of the CORE. My question is what do we do with the opportunity that creates? We need to deliberately and obviously promote one of the excellent frameworks with well publicized and promoted blogs and tutorials targeted at casual user.
This includes full cycle: development, testing integrating into production, upgrade, and system retirement.
@silent, @chris: As sri has said on IRC, there probably shouldn't be a framework in the core anymore, the web is too much of a moving target at the moment and for the foreseeable future. I already do my best to promote Mojolicious. I blog, answer SO questions (both Mojo-specific and CGI), and write software which uses Mojo (like Galileo). The best way to promote good software is to promote it :-)
No, we don't have to promote something else. Those other things can be installed from CPAN with a single command. We don't need to put everything in the core.
The only difference to the end-user by removing CGI.pm from the core is that the small number of people that use it will need to type "cpan CGI" before they first use it. After that it'll be like it was never gone.
In fact, they likely won't even need to do that. Let's face it. The reality today isn't much different for the end-user. CentOS and Red Hat Enterprise Linux put CGI.pm in a separate RPM package and it's not installed by default when one installs the Perl RPM. If a user of CentOS or RHEL needs CGI.pm they might already find it not installed, despite that it being included in the Perl core. They can type "yum install perl-CGI" or they can type "cpan CGI". Either way, it's not like much will be changing. Their system administrator will likely have it already installed for them when they build the server.
Meanwhile, Windows Perl users, like me, will likely use Strawberry Perl or ActiveState Perl. Both of those Perl releases include a ton of extra, non-core modules. I'm sure CGI.pm will continue to be one of them even if it's removed from the core.
The bottom line is that CGI.pm will likely still be installed on Windows versions of Perl and Linux/Unix versions of Perl because the package maintainers will include it regardless of whether it's in the Perl core.