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.
  • The fact that you have to have adept-level Perl 5 experience to understand how to use Perl 5 (the language) in the fashion most useful for novices is a huge problem.

    • So what do you feel is the solution, and what are the small problems that would go away once we had a working candidate solution?

        • The only major problem with this is that most of the novices - at least those I encounter - need to use old versions of perl.

          So the usefulness of this would only be seen later down the road and only by some of the new users.

          But one needs to step on the road to get there.

  • I don't try Padre because (1) it's a pain in the ass to install on Snow Leopard via CPAN or .dmg; and (2) I have no reason to use a Perl-specific text editor when I pay the bills with things that are at least partly not Perl. The Google juice from a bunch of fanboys posting "X, the Y IDE" will not encourage me to use X.

    • What does your rant have to do with your subject line? Is the default OSX Perl compiled without threads? How does your rant address Adams post?

      PS: I'm a vim user and will always be. I write C++ more or less all day. Yet when I have to refactor an icky bit of Perl, I switch editors because I'll take all the help I can get. Works fine for me. Doesn't have to work for you. Tough luck, get on.

        • You really don't have to explain why you are not trying Padre. The majority of the Perl community have not tried it (yet) and that's totally ok.

          IMHO "changing the Perl community" did not mean every Perl hacker now will have to use Padre.

          I never thought Padre would catch any measurable part of the vim/emacs users to change their editor. Maybe once in a while, as tsee mentioned, they will use it and maybe they will recommend it to novices.

          So the major change can come from:

          1. New people coming in to the P
      • I didn't say "is changing", merely "changes".

        The concept/implementation of Padre taken over long time scales will change (and has started to, but only in tiny corners here and there) the nature of the Perl community.

        I don't claim that this change has happened yet in any major tangible way.

        But I see it coming...

  • 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

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

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

    • 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: []

      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 []

      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.

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

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

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

  • I recently thought of installing Padre on the most recent CentOS (which, in case you didn't know, is a community supported enterprise version of Red Hat Linux). The huge number of modules that need an upgrade is discouraging: it wants to upgrade 24 modules (and install 81 more), even after I already installed Wx.

    The main problem I have with that is that I don't want to change anything in the system Perl, as this is contrary to the spirit of CentOS: don't upgrade anything that is stable, as the upgrade might

    • Often the new modules are needed.

      There's a lot of work "on Padre" that actually goes into various dependencies, resulting in new releases and thus new dependencies.

      The ORLite family alone has gone through 10-20 releases to add embedded database features that Padre needs.

      0.56 was a bit more aggressive than most, since it bumps Module::Build and ExtUtils::MakeMaker to current, had some ORLite upgrades, and a few other minor things.

      Some releases are worse than others, but it's our preference to push developmen

    • We are aware of the fact that it is difficult and time consuming to install Padre from source hence we are encouraging the downstream distributors to include Padre and its major plugins.

      In order to allow you to use the latest (or almost latest) Padre on Linux we also have an experimental version of it that includes everything you need - even a threaded Perl.

      See the Linux section on the download Padre [] page.

      • Interesting approach — if only it worked... It turns out not to be so easy.

        I tried the "experimental" "Padre Stand Alone for Linux", but it immediately died, complaining about an incompatibility between Wx and ("GLIBCXX_3.4.9 not found").

        Anyway... Do you see this approach as a solution for all big projects in Perl? Building all these binary distros seems like a lot of work to me. Plus, with several projects, you get a lot of separate file trees, with possibly a lot of overlap. That may

        • I am not surprised it did not work - I tested it only a very limited number of platforms. (Namely 1) but still I am sorry to hear that.

          As I understand in order this to work we need to build a statically linked perl and wxwidgets and apparently this was not the case.

          I think this can be one approach though I hope this could lead to a package similar to Strawberry Perl Professional but for Linux and similar OS-es which would mean other desktop application could use it as a platform.

          I still think inclusio

    • The Strawberry team is going to bundle BioPerl in the default install of Strawberry Professional, which will also come with Padre pre-installed.

      So we can offer than a zero-effort bootstrap into a BioPerl environment.