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

use Perl Log In

Log In

[ Create a new account ]

chromatic (983)

chromatic
  (email not shown publicly)
http://wgz.org/chromatic/

Blog Information [technorati.com] Profile for chr0matic [technorati.com]

Journal of chromatic (983)

Thursday May 28, 2009
08:46 PM

Comparatively Speaking

[ #39046 ]

Number of stable Perl 5 releases since the Perl 6 project began in summer 2000: 13.

Number of stable Rakudo (Perl 6 on Parrot) releases since the Perl 6 project began in summer 2000: 17.

Before you tell me how unfair a comparison that is and how you hate my hair and I'm a horrible person, let me add a disclaimer: Perl 5 has several orders of magnitude more users than Rakudo.

Before you get all smug and tell me that I'm correlating meaningless numbers for no good reason, let me revoke part of that disclaimer: in a healthy project, at least some of the users also contribute something back.

The only interesting question to me now is "Why not?"

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.
  • They're all writing their extensions as CPAN modules.
    • Also getting on with their day jobs by using Perl.
    • That's because they have no choice.

      • Exactly the opposite -- thanks to backwards compatibility, they *do* have a choice, and that's a big part of why they bother to contribute.

        • If Perl 5 had a better class declaration and management system in the core, there'd be no need for Mouse, Moose, Squirrel, and dozens of other modules in the Class:: namespace.

          That has nothing to do with backwards compatibility (at least in a positive way).

  • In November/December, I built an alpha release of "Vanilla Perl 6" (combining Parrot and Rakudo).

    I found it to be uninstallable (because it hard-coded all the filesystem paths at compile time which made it almost impossible to make an installer) and it leaked memory so fast that most simple test benchmarks I created consumed more than the 2gig process limit after running for a few minutes.

    I concluded that the implementation was not sufficiently stable for me (as a person who doesn't know C) to do anything u

    • Yeah, I don't know .. I don't think it's the responsibility of the upstream to maintain the distribution packages, too... looks like Allison is maintaining the parrot deb anyway though!
      • It's the responsibility of the upstream to make it both possible and (ideally) easy for the downstream to package it.

        For your new project with no existing downstream channels, it's a fairly basic thing to engage with the people most likely to be your downstream and go out of your way to make life easy for them.

        And for channels without an existing community to do any of the work (like Win32) it's probably going to mean doing it yourself, at least for the startup period.

        Maintaining the channels are one of the

    • I should add that it's a perfectly reasonable point of view to state that because I'm not a contributor, or even a user, of Rakudo I don't really have any right to complain about it.

      But unfortunately that still means I end up not using it.

      • You may have taken my comments the opposite way in which I intended them. I find it very interesting that the project with orders of magnitude fewer users has much, much more active development.

        (By the way, I just fixed a pile of memory leaks in Rakudo.)

        • What do you see the requirements of a "stable" release as, in terms of performance issues like memory leaks?

          • It'd be nice if "stable" releases never had bugs or regressions or memory leaks or misfeatures or incompatibilities, but that's not going to happen. If that's your criteria, you're going to find everything but TeX wildly unsatisfying.

            Obviously you have to set your expectations for "stable" in terms of the project's roadmap, intended purpose, and intended audience, but with those caveats in mind, the single most important characteristic I see is "Does it do what the developers intend it to do so far?"

            My cri

            • I like to use the the same concepts, definitions and terminology for software bugs, regressions, memory leaks, misfeatures and incompatibilities as the medical profession does for human bugs, regressions, leaks, misfeatures and incompatibilities. The medical profession has a lot of experience with issues that present shades of grey.

              For (medically defined) chronic conditions, like memory leaks, you can use assessment criteria similar to those for mental illness.

              Many people present degrees of dementia, psycho

              • I find quibbling about the definitions of words very dull, but....

                I'd suggest that when most people use the word "stable", they refer to a release that is free from debilitating defects for the majority of users and use cases.

                All I can find from you about these "debilitating defects" you found are two comments in IRC -- no bug reports, no messages to the mailing list, no description of steps to reproduce, no context as to what you were doing to trigger them. I started investigating Rakudo memory leaks in

                • Nobody likes quibbling about words. It's just that your definition of stable seems to differ from many people.

                  I did a fairly simple three line program with a loop in it, and it consumed all my system memory in about a minute.

                  It possible that it's just me jumping to conclusions.

                  Because it did it so fast and so blatantly, and we were still at pre-1.0 releases, I just assumed that it was a known problem, and moved on because I lacked the time or skills to investigate it further.

                  I didn't really take the time to

    • For the record, I totally agree that Rakudo's current installation is very sub-optimal. Part of the reason for this has been that until recently (within the past week), Parrot didn't really provide sufficient hooks for us to be able to build and run Rakudo against anything but Parrot's build tree, short of doing a fair bit of copying things around and specialized linking to make it work.

      I just haven't wanted to invest a lot of my time into building (temporary) scaffolding to work around the missing pieces

  • Which release is the "stable" release?

    After seeing your blog post, I went to rakudo.org, and I see:

    On behalf of the Rakudo development team, I'm pleased to announce the May 2009 development release of Rakudo Perl #17 "Stockholm". Rakudo is an implementation of Perl 6 on the Parrot Virtual Machine [1].

    If not even the Rakudo announcements say that it's anything more than a developer release, then why would people be expecting Rakudo to be ready for more than fiddling around because they're interested in

    --

    :wq!

  • You say:

    Number of stable Rakudo (Perl 6 on Parrot) releases since the Perl 6 project began in summer 2000: 17.

    Patrick's latest release announcement [perl.org] says:

    On behalf of the Rakudo development team, I'm pleased to announce the May 2009 development release of Rakudo Perl #17 "Stockholm".

    (and the previous 3 announcements are similar - I didn't check further than that.

    • If I recall correctly, the intent behind the wording of Rakudo's release announcements -- as well as its version numbers -- is to reduce the possibility of people expecting that any monthly release represents the whole of Perl 6.0.

      I hate the linguistic games around "stable" and "maintenance" and "development" almost as much as I hate the magical thinking around version numbers.

      With that said, I use the word "stable" to mean "passes tests on supported platforms" and "performs as intended". It's not the fina

      • Rakudo uses the phrase "development release" primarily as a way of indicating "No, we aren't claiming that it's Christmas yet." More formally, it's an explicit recognition that there are significant portions of the Perl 6 specification that Rakudo doesn't support yet.

        We don't (yet?) make any official claims about Rakudo's suitability for given purposes. Do I think Rakudo is ready today for a wide variety of general-purpose applications? No. Can I conceive that Rakudo today could be usable for more than

  • Was this blog post just a troll against perl5 development? Confused.

    • It's a serious question.

      Very few people use Perl 6. Hundreds of thousands of people use Perl 5. Many businesses depend on it. (Yours does. Mine does.)

      Why are Perl 6's developers able to make and meet commitments to release software and Perl 5's developers unable to do so?

      There are many possible answers. Perhaps no one wants new releases of Perl 5. Perhaps it's impossible or infeasible to release stable versions of Perl 5. Perhaps publishing a ROADMAP or a rough schedule of Perl 5 releases is a bad id

      • These are just people's general opinions, from what I can tell. All these things can slow down development.

        • Perl 5 has years of cruft built on arcane internals.
        • Perl 5 bugs have a greater risk of breaking more people's code.
        • Perl 5 has a lot more in the core and thus more to manage.
        • Perl 6 can and does make changes to backwards compatibility without impacting their user base significantly. P5P argues long and loud (thank goodness) about risking this.

        I could probably come up with several more reasons if I t

        • All these things can slow down development.

          Be careful not to fall into the trap of thinking that the pace of releases must precisely match the pace of development or vice versa. I have no objection to slow development nor careful development. I object to unsustainable development.

      • Well Perl6's development process is new, and thus nimble and agile. Perl5's is slower because it has a lot more history.

        Is it changeable? Probably.

        Is it totally broken? Not really, though I do wish to see 5.10.1 some time soon!

        A regular release is a nice thing to have, but it doesn't always create the most stable platform or the most confidence.

        It might interest you to note that SpamAssassin has the same problem right now - it's been forever since the last release.

        One thing I did think about with perl5 is t