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 educational setting is that you get a decent GUI quickly which is more like "real programs" for anyone except die-hard CLI addicts. Ditto PHP, but for dynamic web pages on shared hosting.

    Here are some areas where I think Perl is not as easy as it could or should be. A lot revolves around CPAN, since that is one of the strengths of Perl and we're not making it easy enough for people to take advantage of it:

    • Installing CPAN modules locally

      CPAN(PLUS) should be designed for the case of a non-root user installing modules locally for use with the system Perl. local::lib [cpan.org] has the right idea, but even bootstrapping it isn't the easiest things for someone new to Perl. What it does should have been built into CPAN(PLUS) ages ago. (I have a feature branch for CPAN.pm that provides this capability and will be looking to merge it after Perl 5.12 is released.)

    • Automatic, transparent CPAN configuration

      The latest dev of CPAN.pm is much less annoying and verbose that it used to be. It does a pretty quiet auto-configuration and can even automatically locate mirror sites. But it could be better yet. A lot of the guts should be hidden from the ordinary user.

    • CPAN popularity metrics

      CPAN has nearly 20,000 distributions. Even search.cpan.org gives dozens or more results on a search. Figuring out which of several similar modules is time consuming, even for experts. Combinations of CPAN Ratings, CPAN Testers results, etc. help. The top 100 list is another useful tool. But we need something better that either ties all these things together or replaces it with something else.

    • Shared hosting website deployment as easy as PHP

      I can't do anything but draw the parallel. It makes the jump from HTML to a dynamic site really easy. No messing with frameworks, templating, HTTP engines. Doesn't HTML::Mason work more or less that way? It doesn't have a mod_php to go with it, but I wonder if something in between HTML and MVC would help people who want simple dynamic sites (backed by the power of CPAN.

    • Improve parallel processing and leveraging multi-core systems

      Perl threads still suck. The best alternative is to fork off the entire interpreter and cobble together some way to collect results? (Parallel::Iterator, for example). There's got to be a better way to do this.

    • Smart defaults in core

      Not just strict being on by default, but the core modules themselves should be a smart set of tools for modern programming tasks. I'm not saying the core should have the kitchen sink, but there should be some basics that come installed with any Perl without making users mess with CPAN. Things like HTTP, SSL, DBI (and probably SQLite) would be good places to start, I think. I'd like to see a standard OO included, but suspect that's too controversial to achieve.

    How's that for starters?

    -- dagolden [dagolden.com]

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

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

    • You're idea about deployment as easy as PHP is spot on. The PHP concept of a web-based installer is really intuitive to work with for a novice.

      I've been pondering this idea here:

      http://github.com/robinsmidsrod/unnamed-perl-cms-project/blob/master/README#L82 [github.com]

      If the novice could just download and install a web-based CPAN installer/updater to put on their shared hosting account and then just view that UI in their web-browser a lot would be done. To avoid the potential problem of a CPAN compiler fail (or lack of

    • On parallel processing:

      There's got to be a better way to do this.

      No dynamic language has found it yet. Even 2 full time Google engineers have failed to find it for Python [google.com]

      CPython has a Global Interpreter Lock, single threads the interpreter, and hence single threads compute intensive task. [C]Ruby has "green threads" (i.e. it does the thread scheduling). There's no prior art. There's no proof that the problem even has a solution.

      • It's really hard to imagine a solution. Particularly in perl. In the face of automatic conversion of SVs on read access in new contexts, this seems utterly impossible without crazy locking.

      • As I noted above, Clojure is a dynamic language that provides a solution. There is prior art, it just doesn't look or feel like Perl/Python/Ruby.
        • Sorry, I wasn't clear enough. My fault. Prior art for a dynamic language implemented in C. Clojure is a dynamic programming language that targets the Java Virtual Machine. (To the best of my knowledge) Jython does threads just fine - it's CPython that can't, and even the folks at Google working on Unladen Swallow can't see how to take that Jython know-how and port it to the C implementation.

          • I don't think there's anything stopping Clojure from being implemented in C if they actually wanted it. The problem for CPython and Perl isn't that they're in C, but that the entire language is based on the idea of default mutability. Clojure was designed from the ground up with a different multicore-focused approach to state in mind, which is why it works. You'd have to fundamentally change Python and Perl as languages, no matter what their implementation, to get them to do handle threading well.
            • Good point.

              Sadly, once again the punchline from the "Irishman giving directions" joke bites:

              If I were you sir, I wouldn't start from here.

    • You mention this about Java's success, but many of the pain points you've elaborated on are details pertaining to the CPAN and deployment.

      If Adam is right about bigger solutions being the impetus to solve more detailed problems, then ease of learning/setup/deployment for the CPAN should have been solved years ago. Or, maybe I'm mis-interpreting.

      As for my "candidate solution", making "gimme a GUI" quick is something I've been trying to do with FreeTUIT. After years of developing with wxWidgets, I've gotten

      • If you are going to move forwards with PerlQT, just make sure you solve (early) the problem of building and installing it on the three main desktop targets effortlessly (Win32, Mac, *NIX Gnome/KDE) because if you can't install a desktop program on the three main desktop environments, you lose a lot of traction immediately.