John Siracusa writes: > To bring it home, I think packaging and distribution is important > enough to warrant a standard, core-supported implementation. Yes, > it's great to be able to roll your own solution, but forcing the issue > by providing nothing but the most basic features required to bootstrap > a custom solution leads to too much variety and confusion. For some > features, familiarity and standardization are more important.
That only works if the 'core' feature is unquestionably 'right' and can't be improved upon by somebody else (or indeed by the same person, but later). > Furthermore, every "non-core" implementation will necessarily be > uglier than the built-in system. What makes you think that? There are plenty of counter-examples, in terms of things that Perl 5 has in its core (or in its standard set of modules) that others have improved on later. For example in the last couple of years several popular File::Find alternatives/enhancements have found their way to Cpan. It's arguable that current releases of Perl shouldn't have File::Find (or CGI or Text::Soundex or whatever) in the core, since better ways of doing this are elsewhere. In some ways putting features in the core actually stifles innovation, because it doesn't encourage people to come up with novel and better ways of addressing that problem. As a minimum if a feature goes into the core then considerable effort has to be put into ensuring that it is done right, or at least as well as possible and in a way that minimizes the chance of improving or extending it in the future. That takes time. Suppose the time to write the best possible packaging feature is n months. That means that Perl 6.0 could be released on date d without it, or on date d + n with it. Should everybody who doesn't need a packaging feature have to wait for it to be written before Perl 6.0 is released? Suppose instead that 6.0 was released without packaging on date d and 6.1 was released with it on date d + n: that means that you still get your packaging feature on exactly the same date, but it doesn't hold up 6.0. More to the point, once Perl 6 is about people can try writing their own packaging systems, publish them, improve on each other's and so. Perhaps after a few years we will collectively have the experience to see which features and interfaces are most appropriate, and maybe even there's a consensus that a particular packager is the way to go. If many people are all using a single packaging system, then that would be good time to add it to the core, perhaps shipping it with Perl 6.4. Adding a packaging system before then is premature, because there's a very high chance that somebody will write a better alternative packager, leaving Perl in the situation of distributing something that isn't recommended. Smylers
