I'm all in favor of chromatic's suggestion to dump most of the core Perl modules. But I think he left out what might be the most important (and most controversial?) part of such a plan: providing a proper guide to CPAN.
In a previous post I complained about the difficulty of figuring out what MP3 tagging module to use. CPAN is great at providing alternatives, but not terribly good at providing a way to evaluate the pros and cons of those alternatives.
Now, with something like MP3 tagging that is just an inconvenience. But if it happened to core modules, it would be a disaster for Perl. The best thing about the core modules is you know they are a standard. If you want to do, say, standard file handling, you us IO::File, simply because it is there. But if it's not there, and you're a beginning searching CPAN, you'll be confronted with dozens of modules that sound like they might do the right thing. It's an utter nightmare for the poor beginner who just wants to get his twenty line script running.
It seems to me the answer is a guide to CPAN, something that points out what you should probably use and what you should avoid at all costs. Maybe it should be a web page, or a wiki, or just a standard module package that everyone should install. But something is needed, and it will have to be opinionated to be useful.
PS It is especially needed because you've got to think people will start re-evaluating those basic modules in light of the past ten years' changes to Perl (and the even greater ones coming chromatic envisions). Moose::IO::File anyone?
Subscribe to:
Post Comments (Atom)
The problem with such a guide is 'who decides'. Maybe this can be just left to the people that do the Perl 5 maintenance - but I am sure there will be people with different ideas. And if you just let it to be done democratically - then you'll end up with the whole CPAN - after all nobody would upload his module to CPAN if he does not recommend it.
ReplyDeleteAgreed that is the tricky part. But I still think it will be very much needed if chromatic's suggestion is carried out.
ReplyDelete@zby: I don't think that's entirely true. A non-trivial chunk of CPAN is just old shit that no sane person uses any more. For example, my module Alzabo. I don't use it for new projets, nor would I recommend it to anyone else. Yet it's still on CPAN (as it should be, since some old app out there may need it).
ReplyDeleteThat said, even after you remove all the old-and-dead cruft, there's still a ton of stuff on there, and often there's no consensus on the best of breed module(s) in a problem space.
As somebody who helps keep the core in good shape, specifically with respect to dual-lived* modules, I can tell you that chromatics rant is so far off the mark of reason that I didn't even bother to leave a comment there. Now, as far as I can tell chromatic is a smart guy. According to a couple of people who actually know him personally, he's also a really nice guy.
ReplyDeleteRegardless, I can't but point out that his so-called "plans" are nothing but pie-in-the-sky fantasies. Not only has he done nothing but finger-pointing, but the idea to remove all modules from core is simply ridiculous. It directly flies in the face of making CPAN more accessible. This being said, we're actually deprecating (and later removing) modules from core. But certainly not even close to "all" modules. Furthermore, his comparisons between parrot and perl5 core are straw-men. They're not projects with the same -- heck not even with similar -- characteristics. They're not comparable. They won't be able to have the same release procedures. This is obvious to everyone involved but chromatic.
But what really annoys me above all else is that he cultivates the sentiment that the perl5-porters are this strange bunch of folks who never get anything done and won't even accept the generous help of superior minds. I can tell you what we are. A very diverse group with diverse talents. Some, like Rafael, Nicholas and Dave, have a broad overview over the whole project. Some only know a small portion. We're volunteers working hard. Sometimes visibly advancing at a great pace such as when Yves and Dave had their mad dash hacking on the regular expression engine or when Brandon wrote the C3 mro. But most of the time, the bulk of the effort goes into fixing bugs, and keeping things in reasonable shape. I'm mentioning those two examples for a reason: Brandon wanted the C3 mro enough that he got involved and simply did it. As far as I can tell, people welcomed him. We don't need the nay sayers or self-appointed visionaries. We just need people doing plain old hacking.
* "dual-lived modules" are those modules which are available in core as well as from CPAN. Usually, you may think of the CPAN release as something like the "backports" in a few popular Linux distribution.
Even if his ideas *are* pie in the sky, surely he should be allowed to voice them. The only way we can move forward is by having open, mature discussion about the options available. Completely ignoring the discussion (or at least those who are raising points you don't agree with) gets us nowhere.
ReplyDeleteMy primary concern is that people who don't know the perl 5 core will think chromatics ideas are realistically implementable and useful. Somebody who arrives at that conclusion will naturally look for a reason why they're not carried out. From there, it's only a small step to seeing those ideas being blocked on ideological grounds or even some sort of conspiracy. Neither is the case. What would really help perl 5 is more people working on it.
ReplyDeleteIn this context, I'd like to clarify one of my statements. Quoting my comment above: "Not only has he done nothing but finger-pointing". This was meant to refer to the situation at hand. It wasn't intended to say he hasn't ever done anything of value. That's not true and please let me apologize for not being clearer.
(When I read chromatic's reply to my comment on his blog which quotes this, I was first slightly upset because I felt he was quoting me out of context. Turns out his quote is fine.)
I have seen this discussed previously (sorry I don't have the link). One of the solutions is the CPAN ratings system. IMHO this is a step in the right direction. While there may be several options to perform the same task, usually in an open system like the CPAN the creme rises to the top (that's why you'll find Moose recommended for OO more than say Class::STD).
ReplyDeleteI think more easily accessible metrics would be helpful such as downloads, test statistics, e.t.c. Unfortunately, not many people (myself included) spends time rating modules they use even if they use them very often.