Slash Boxes
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

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • 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.

    • Insistance is futile, you will not be assimilated?

      • 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

        • Maybe the solution a two versions of perl.
          • That idea crossed my mind yesterday. Instead of enabling syntax features at runtime depending on the presence of a command-line flag or use feature 5.10;, use #ifdef to compile in or compile out features. Build one binary without new syntax as maintperl or something and the other as perl.

            This would increase the testing and smoking burden -- and that's a very real consideration for maintainability -- but it provides a backwards-compatible binary as well as a modern binary.

          • 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.