On the removal of some core modules
I’m sure most of the readers of this blog will have seen that both Module::Build and CGI.pm are up for removal from the Perl core. I thought I would toss my $0.03 (inflation) in on the matters.
This makes me very sad, but if I had a vote I guess I vote to remove it. Indeed, I hate ExtUtils::MakeMaker, I know nothing about Makefiles nor the magic that EUMM uses to precognitively manipulate them. I could as easily perform feats of magic with EUMM as I could perform actual feats of magic (that is to say, there is almost no chance). I am good at Perl, I can make Perl classes and subclasses do very cool things. I will continue to use Module::Build until there is something better available.
The sad thing is though, MB is bad too. It is extremely overdesigned and for all that the returns are less than good. The underlying object is near impossible to comprehend or extend. The worst part is, given that the object MUST be serialized, its one of the few objects I’ve seen that essentially cannot be! For this reason I have started a port of Module::Build based on Moo (cleverly called Moodule::Build) on my github. It’s VERY far from complete, but it is showing promise. Since the underlying object is a simple Perl hashref (as Moo objects are) serializing should be straightforward and adding accessors and subclass should be as easy as any other Moo(se) project is.
Leon has started his own Module::Build::Tiny and while admirable (and impressive) it cannot do XS yet. Until this is possible or until Moodule::Build or some other candidate emerges, EUMM and MB are the only way to go. I wish it wasn’t true but now that cpan clients can bootstrap build modules, there is no reason to have more than one in the core and MB is not a good example of the Perl we know and love.
That logic goes first so that I can say that:
There is absolutely no reason that this module should still be in the core. I have seen arguments ranging from nostalgia to pleas that some companies do not allow any external modules to be installed. As to nostalgia, we can tip our hat to the past without propagating it further. To those companies who say that there may be no external modules (and I feel for their employees as I say this) you must be out of your mind!!
CGI.pm is no better than other web frameworks simply because it is in the core. Do you believe that because it is there it is better vetted or otherwise recommended by “the Perl people.” This is completely backwards!! We should discourage its use and do so by removing it. The crutch of Coredom has allowed it to live on much too long! If there must be some framework in the core (and no I don’t expect this to be Mojolicious, nor would I want its progress slowed down by being so), perhaps someone could make some minimal modern framework would could be included. Surely there must be some ultralight so-small-it-can-barely-work-but-just-does thing that could be added.
In one of the posts I saw, someone recommended that perhaps some of the constituent tools, those that are common in all frameworks, like escaping html entities, could be encorified. But please lets not encourage or even associate with the kind of code that we are trying to compel the world to forget about. Perl can reclaim some of its good name by showing off good code written in a modern way.
We have the tools lets not keep permitting newcomers and old-hat-haters to continue to see bad Perl lying around and indeed semi-blessed by staying in the Perl core.