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.
  • I tend to think of this along the lines of "making hard things easy and impossible things merely hard". With that in mind, the frontier has shifted since Perl was developing rapidly.

    My gut feeling is that the "wow" factor has become harder for Perl to achieve because what wows people isn't insanely great string, dataset and administrative task manipulation. People want to see results quickly. That's not just about the learning curve -- it's the end-to-end process.

    Part of the advantage of Java in an educa

    • "Improve parallel processing and leveraging multi-core systems"

      I agree about this. It's important going forward.

      Also: Point me at a dynamic language that does this better. No. Not Python. They don't do concurrency. They do the same as Coro does and call it threads.

      As for extending the core: We both know that's against the opinion of the powers to be. And the powers have the good reasons for their agenda. The correct way to do this is an extended core project, either via EPO or not. Have releases of that wit

      • As for extending the core: We both know that's against the opinion of the powers to be.

        The "powers to be" aren't powers. We're just the people who do the work, rather than the talking.

        If people feel that there should be a bigger core distribution, please branch [], add what you think needs adding, advertise it, get it established, demonstrate that you can support it on an ongoing basis, and if it's proven better than the current approach for the core distribution, then likely

        • I agree that it's not fair to blame "the powers" -- and, frankly, tsee and I are also among that crowd these days. We need more dialog on what is achievable and supportable and what not. But I think saying "fork perl and maintain it" is an overreaction.

          I was the person that first built and released Strawberry Perl [], so I have some experience on this topic. It was actually fairly easy. Build Perl, drop in a pre-configured CPAN::Config, and install extra stuff right from CPAN. The "hard" part was getting everything to work on Win32.

          That sort of approach could potentially be done directly in the Perl core -- though probably building from bundled tarballs, not downloading directly from CPAN. I suspect a lot of dual-life modules outside the module toolchain could be packed in core as tarballs and built/tested by the toolchain rather than by the hybrid process that happens today. Maybe one day I'll have enough round tuits to make that happen.

          Even without that, I think the (admittedly recent) trend of Perl's development is making it easier to coordinate dual-life modules in core. One of those trends was giving out commit bits to dual-life maintainers like me, so updates don't all fall on the pumpking and a handful of committers. But the more recent trend of time-boxed 5.11.X releases means that having the absolute latest/greatest version on CPAN also in core isn't as much of a release hurdle. I think we can do more to make the process smoother.

          I'm not suggesting throwing everything and the kitchen sink into core. But I do think there needs to be a renewed discussion of what "out of the box" functionality should be in core. One that I feel adamantly about is that CPAN should be able to bootstrap itself via HTTP without requiring any external command line tools. That is my #1 project for Perl 5.13.

          Hopefully, I have enough track record as a "doer" not just a "talker" to do a credible job of it and convince people that this will make life easier for users and maintainers.

          -- dagolden []