Tidbits: CGI.pm removal - a data point

Can't say I have been fond of the CGI module that comes with Perl, or rather, once came with Perl, as it has been removed.

I certainly don't miss it, having used it only twice in my life (without exactly falling in love with it, but it did seem appropriate for the two simple throwaway scripts I used it for). Interestingly, there doesn't seem to be a viable drop-in replacement that fixes any of its (supposed) design issues - and suggesting people to rewrite their scripts in monster frameworks such as Mojolicious/Plack/PSGI/Catalyst (as perl5-porters do) is a joke - learning those would dwarf the effort to do a simple hack in CGI.pm.

Recently, I stumbled over a web site that no longer worked, following some links from another site. As with so many sites, this one just happened to work because Perl had a high level of backwards compatibility, so the site just worked as long as Perl kept backwards compatibility, but stopped working recently. And as with so many "legacy" sites, the owner has no time to fix it.

In this case, the guy behind the site simply decided to rewrite it in PHP:

Wot, no Gamebase64.com?

I have changed hosts and the new guys have a newer version of Perl
(which this site is written in) that doesn't include the ancient CGI
module by default (which again the site uses) so nothing is working.

I could do workarounds but at this stage and because there's not too
many script pages on the site, I'm going to rewrite it in PHP (which is
what I have been using for the past 10 years)

So the site is going to be down for another few days but hopefully not
too long...

Needless to say, the few days became a few months and it is still down, so I am not sure what I am more appalled at - that he wants to rewrite it in PHP, or that the content is still unavailable due to Perl changes.

So, this is just another anecdotal data point on the state of Perl compatibility with itself. Or the recent lack thereof.

Update: Dave Cross and a few others speculate that the website is not actually truthful in that the real problem is not a newer perl that doesn't include CGI.pm, but in fact the hosting server using a very old perl (5.8), which includes CGI.pm, but the hosting provider somehow didn't install it. The hosting provider supposedly is blacknight hosting (although the server itself is by domainfactory in germany, a different company, so things do not quite add up).

That might well all be true, but of course completely fails to address my criticism, namely that perl has become the sandbox for experiments, and that backwards compatibility is now (officially) a thing of the past.