develooper Front page | perl.perl5.porters | Postings from June 2006

Re: Its time we set the score straight on Perl 5 and Perl 6 and debunkour own self-generated FUD.

Thread Previous | Thread Next
Randy W. Sims
June 23, 2006 16:11
Re: Its time we set the score straight on Perl 5 and Perl 6 and debunkour own self-generated FUD.
Message ID:
Adam Kennedy wrote:
> Randy W. Sims wrote:
>> Adam Kennedy wrote:
>>> Carp...
>>> utf8
>>> warnings
>>> A few others, but yes, it should look something like that
>>> Level 1 - Perl, strict, Carp, warnings, utf8, a few other small things
>>> Level 2 - Level 1 + whatever is required to have a working CPAN client
>>> Level 3 - Level 2 plus a large number of other common things...
>> Is the layered approach sensible past "Level 2" as opposed to grouping 
>> modules by task? Or should there be anything at all past Level 2? The 
>> more sets, the more work to support them. But then, it seems to be 
>> much more reassuring to some users, judging from other posts, to have 
>> a "supported" set of modules.
> Indeed. That's part of the reason for the discussion at the hackfest, to 
>  come up with some idea of how we handle that.
> Certainly 1 and 2 are straight forward.
> But there's less clarity on what we might include beyond that.
> Something like Task::StrawberryPerl (which I've uploaded in advance of 
> Strawberry Perl actually existing) may be one method for achieving that.

Just to clarify, when I mentioned task oriented bundles, I intended 
something along the lines of:

  Task::WebDevelopoment (html, cgi, etc)
  Task::Algorithms (Common algorithms and data structures)
  Task::Text (Text Processing, incl Regexp)
  Task::Protocols (http, ftp, etc; presumably a minimal set
    of these would also be incl'd in "Level 2" for;
    this would be the complete package)

The goal mentioned most often for growing the core is that there are not 
enough *officially suppported* modules; some companies have a limited 
view of using any module not officially supported (although, I 
personally don't see how this is different than evaluating and using 
proprietary and commercial solutions: some are good, some suck, it's up 
to the developer to make sure as product is suitable for use). The only 
way the task oriented groupings would satisfy these users would be to 
choose a namespace and close it except to a limited set of "official" 
task sets, where presumably some committee would decide which sets to 
produce and which modules make up each task set.

This seems the best middle of the road solution that could potentially 
satisfy the minimalist group (me, incl) and the kitchen sink group.


Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About