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.

Why Ruby is prettier and Padre changes the Perl community 9 Comments More | Login | Reply /

 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 actually your version will be folded back as the official core distribution.

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

        • 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

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

        • 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 [strawberryperl.com], 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

Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.