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.

  • It seems odd to lump everything not in CPAN into one amorphous category to be disregarded. Imagine if Microsoft ignored all software not distributed by Amazon, or if Apple ignored all iPhone apps not... wait, bad example. In an open development community, it seems inappropriate to require a specific distribution channel to be used in order for your feedback to be considered on what features are key.
    • It's not deliberate. It's that analyzing all code on the CPAN is so much easier than analyzing code anywhere else that the latter seems intractable.

      • With the analysis tools being made publicly available, input can be solicited from the community at large, and from a sampling of known users. As this is an old, long-standing problem, experiences from other development communities can be used. With the greater amount of interconnection today, it should be easier now than in the past to enable feedback and data to be collected.