NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.
All the Perl that's Practical to Extract and Report
about I/O disciplines and I should retire to the Tassili-in-Aijer
mountains in Sahara as a camel herder :-)
-- Jarkko Hietaniemi
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.
Agreed (Score:1)
No competent project manager would agree to manage something unmeasurable.
My argument remains that attempting to do so with regard to the DarkPAN is futile.
Re: (Score:2)
Insistance is futile, you will not be assimilated?
Re: (Score:1)
If you can't observe the DarkPAN, its contents, its needs, and the consequences of any change to Perl 5 are opaque. I believe that basing design decisions on the inobservable DarkPAN is a mistake.
Observing (at least part of) it gives the Perl community a better chance to evaluate proposed changes in documentation, training, best practices, idioms, workarounds, core library changes, and core language changes.
We may still disagree about the nature and scope of changes as well as their most appropriate or use
Re: (Score:1)
Re:Agreed (Score:1)
Or more. That seems to make sense when there are too many egos for one project. Linux does something like this, with the various branches (e.g. "-mm") coexisting with Linus's tree. Of course there's the usual drama, but they somehow manage to keep sharing patches.
Reply to This
Parent