Stories
Slash Boxes
Comments
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.
 Full
 Abbreviated
 Hidden
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 http://perl5.git.perl.org/perl.git [perl.org], 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

        • Nicholas, you took this wrong. But I'm also grumpy this morning, so maybe I just phrased it wrong.

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

          They're powers for that very reason. I'm perfectly fine accepting the decisions of those who do the work. I think that's the only realistic way to run a large volunteer-only project. But you quoted only part of my comment. In the next sentence, I acknowledge that there's good reasons for this stance. These reasons are specifically related to:

              "demonstrate that you can support it on an ongoing basis"

          Which I understand to be the main idea behind making the very core as slim as possible. As it stands, it's all an act of balancing "ease of maintenance" vs. "out of the box user experience". Given the constraints on volunteer maintainers, erring on the side of maintainability is the only way to go. That and the fact that I do not have the time budget to fork the core doesn't mean I can't *wish* for a "batteries included" approach. Maybe, on a spare week-end, I'll try to come up with a mechanism that allows people to drop tarballs in some directory to have them build alongside the core. That would make the "so shut up and do it yourself, it's easy, just some work" argument more compelling.

              "Actions speak louder than words, as Strawberry [strawberryperl.com] shows."

          I'm not sure why you throw that at me. I've been involved in that to some extend by fixing win32 bugs in various modules when the whole thing was in its infancy. So thank you very much.

          • I just phrased it wrong.

            Yes, just that. Sorry for annoying you. I know that you contribute massively to keeping the dual life modules in shape. I'm not as aware of the other things that you do.

            But I don't like the phrase. Particularly as it can be taken out of context, and likely will be some people who read it. It implies that the people referenced have the power to change that policy. Whereas the policy is totally defensive - we're already stretched beyond what a volunteer group can manage. If we tried to

          • Maybe, on a spare week-end, I'll try to come up with a mechanism that allows people to drop tarballs in some directory to have them build alongside the core.

            I thought that, at least in theory, you could just untar a distribution in ext/ and tell Configure to build it? I've no idea if this still works with the ext/ dist/ cpan/ rearrangement, though.

            • I thought that, at least in theory, you could just untar a
              distribution in ext/ and tell Configure to build it? I've no
              idea if this still works with the ext/ dist/ cpan/
              rearrangement, though.

              Almost, but not quite. It shouldn't be hard if you have any idea how the perl build process works, but the point would be to enable doing this without any special knowledge at all. Off the top of my head, you will...

              • ... have to make sure the build process of the module doesn't do any strange things that aren't compatible with a non-installed perl.
              • ... have to decide where the module is to be installed: core lib, site lib, vendor lib?
              • ... have to add things to MANIFEST.
              • ... probably hunt down and torture an
            • This is only going to work for trivial cases.

              Strawberry currently has 50 odd extra modules, mostly crypt, build/cpan upgrades, and database clients.

              It's already bloody hard to maintain the list of dependencies by hand.

              You really need to be able to bootstrap from core -> ( list of classes ) to maintain sanity.

              Just installing Padre takes 100 packages and the dependency list changes (both up and down) on a weekly basis.