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 with every new perl, plus some. Then convince the distributions that they want a meta package for the extended core. It'll stand a small chance of catching on.

      • The correct way to do this is an extended core project....

        Exactly; that's the best way to do it well in any sense. If Strawberry has demonstrated anything, designing for the the utility of end users is inestimably important.

      • 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

          • 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

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

        Clojure is the only dynamic language that's done the multicore thing properly. To do that required a dramatic rethinking of how a language should be structured, leading to real innovations in how data structures are represented by the language internally as well as a software transactional memory system built on top of it. While I suppose it's possible to implement these things in perl, it'd become a radically different language if you did so.