The Long Death of CGI.pm
perlhacks.com
perlhacks.com
yum install 'perl(CGI)'
yum install perl-core
The article claims it's not really what you would recognise as Perl and Red Hat [strips] out many parts of Perl that they consider non-essential both of which are plainly untrue.
The point is that the standard perl RPM does not contain everything that you would expect to see in a Perl installation. And whilst I agree that it is simple enough to fix that situation, many people running low-end web hosting services don't realise that the standard Perl installation is stripped back and don't do anything to rectify this - as demonstrated by the example in my article.
I really don't mind Red Hat providing a standard stripped-down Perl RPM. I just wish they had called it "perl-minimal" or something like that, saving the name "perl" for the full Perl RPM.
The problem with dumb hosting providers is dumb hosting providers. I'm sure they'll find other ways to screw things up even if the package name was changed. Who uses web hosting these days anyway, when you can fire up a cloud instance and install whatever you like?
That's not going to fix Centos 6 and 7 - both of which are mainstream in the web hosting industry right now.
And I've had this conversation with the Red Hat Perl packagers. They can't see the problem.
> The RPM packaging is (also IMHO) more rational.
To be clear, I also like the way that Red Hat splits the Perl RPM into individual RPMs for each module. My argument is only with the set of these RPMs that are installed alongside the main perl RPM.
> Who uses web hosting these days anyway, when you can fire up a cloud instance and install whatever you like?
Not you and me, of course. But I'm talking about people with no technical knowledge who rent some cheap web space and run a CGI guestbook program.
We could just ignore them. I suppose. Let them all switch to PHP. To be honest, I think most of them have already gone down that route.
I don't think this is true. I count a total of 6 modules added and 10 removed in stable releases of Perl from 5.12.0 (that is, since Perl adopted its current release-management process). Corrections welcome if I'm miscounting, of course.
Wordpress is an OK product. On the other hand I reckon php is a bad technology to stake your career on. Perl less so, bear in mind it's been around for several waves of the latest greatest thing and is still going strong. Still I quite enjoy javascript sometimes, it's like a syntactically crippled perl with good vendor support. Perl6 looks cool, I hope I get the opportunity to mess with its async stuff.
Then again, so's GCI.
Fast_CGI helps here of course, but then you have your users needing to be able to create long lived processes which moves the problem to one of memory use and process cycling & other management.
This made me laugh this morning, version 5.22 will probably be included in the 8.0 release? So we have a few years to go. RedHat 6.* is still running Perl 5.10 so no worries about anything breaking in the next 5> years.
Edit: formatting
And, yes, it's easy enough to fix that (pointing that out was one of the main points of my article). But we're talking about low-end web hosting services where the web site owners don't have the root access to do that and the service providers either don't know what is missing or don't care about Perl enough to bother fixing it.
But I still think CGI scripts have their place, and I have written a bunch over the last two years at our company. I get that CGI has a number of problems, but for simple tasks I think it's a completely acceptable solution.
(Just to be clear, I am talking of CGI as in "web server calling an external program through a defined interface", not the HTML-generating stuff in Perl's CGI module - my scripts use Template::Toolkit for generating HTML.)
I don't see the harm in including it. I would think it was enough to document the disadvantages.
The discussion is at http://www.nntp.perl.org/group/perl.perl5.porters/2013/05/ms... if you want the full details. But ultimately, I think they decided that having the module in the core was tantamount to a recommendation for its use.
For a much more modern approach, use Plack/PSGI, and one of the many frameworks built using it.
No one should use Matt's stuff, unless you want huge security exploits.
Yes. That's the point I was making.
Mind you, Matt's CGI scripts are no worse than a lot of PHP that is floating around these days...
(I came to make a cgi-lib.pl compatibility mode gag, but your joke was better...)
And it was everyone's first web language in the day. I was super impressed when ran my first perl script. I was hooked. :-)
As such, I think the answer to your question is eventually you'll have the same depth is Swift that the Perl community has but so far Swift is still behind in tooling and libraries for many things. Since server side Swift on Linux is weeks old, there isn't a simple well known go to library for web work like CGI.pm, or my preference for simple web services, Web::Simple. And of course if Windows is something you need to support Swift won't help you.
You can't do nostalgia for the good ol' days in Swift.
(I remember when my first eCommerce site broke when my webhost upgraded from Perl 4...)
Web pages on shared hosts without a swift compiler, which would be more or less all of them?