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

use Perl Log In

Log In

[ Create a new account ]

pmichaud (6013)

  (email not shown publicly)

Patrick Michaud is the pumpking for the Rakudo Perl 6 compiler. He holds a Ph.D. in Computer Science and was formerly a Professor of Computer Science at Texas A&M University-Corpus Christi. He is currently a software developer and consultant focused on open source development and applications, including Perl, PmWiki, and Linux.

Journal of pmichaud (6013)

Wednesday August 05, 2009
01:42 PM

Building a "useful release of Perl 6"

[ #39411 ]

The most common question I get from people who aren't generally involved with Perl 6 development is:

"When will Perl 6 be finished?"

In some ways the wording of this question bugs me a bit, because the word "finished" implies there's a point at which we all say "We're done" and development ceases (or at least moves to some other phase). But there really isn't a "finish line" for Perl 6, there are just stages of development at which more and more people are able to make use of whatever is currently available.

So, once we eliminate the notion of "finished", the wording is often changed to try to make it more tractable, often by asking when there will be a "stable release", or when the specification will be frozen so an implementation can be completed, or many other variations on the theme. I understand the assumptions behind questions like these, but at the same time part of me thinks "Huh? Those questions don't really fit with the way things really happen in language development..."

The truth is that language design is an evolutionary process, with the design and implementation efforts serving to influence and guide further progress in the other. (See "whirlpool model".)

But there's another important input to the process: "real-world" application programs. We need to know how Perl 6 is actually being used in order to finish parts of the specification and implementation. Indeed, there are parts of Perl 6 (e.g., concurrency) where the specification is incomplete or underspecified precisely because we need input from people writing Perl 6 applications.

But this poses a problem of sorts, because if programmers are waiting for Perl 6 to "finish" before they start using it to write programs, and if Perl 6 is blocking on feedback from applications and implementations before it can progress, then we have a deadlock of sorts.

So, we need a way to break the deadlock. To me, one good answer is to start making releases of Perl 6 that may not implement the entire Perl 6 specification, but that application writers will feel comfortable enough to start using in their projects. I've started to call these "useful releases" or "usable releases". While it might not have every feature described in the Perl 6 synopses, enough features will be present that can make it a reasonable choice for application programs.

In doing this, I'd like to also refocus conversations to avoid words like "finished" and "stable", because they have such varied and strong meanings in this context.

So, here's what the Rakudo Perl project is going to do:

We will make an "official", intermediate, useful and usable release of Perl 6 (an appropriate subset) by Spring 2010.

Of course, we have to decide what will will be included (and excluded) in this intermediate "official release". At the Rakudo BOF on Monday we held a lively discussion about what the release could look like, what needed to be present, and how it could be packaged. During the hackathons and days following YAPC::EU we'll be drafting and publishing the more detailed blueprint for the release. But one of our guiding principles will be to "under-promise and over-deliver", to make it clear what can be done with the release, and to make it very clear which parts of Perl 6 are not yet supported in the release.

A short list of things we know will be in the release (that Rakudo doesn't already have): use of the grammar for parsing, laziness, better support for modules, fewer bugs, better error messages, better speed. Again, our goal is to make something that is reasonable for people to start using, even if it doesn't meet all of the requirements for Perl 6.0.0.

We've also had discussions about what to call the intermediate release. We've considered tagging it as "Rakudo 1.0", but some of us think that the "1.0" name might tend towards "overpromise". We also considered things like "0.5" or "0.9", but these come with the message of "not ready for use", and that's not what the impression we want to make either.

So, yesterday morning I finally got around to thinking about it as "Rakudo 'whatever'". In Perl 6 the * term is used to signify "whatever", so that leads to a working name of "Rakudo *" (or "Rakudo Star").

So, the focus of the Rakudo project is to release "Rakudo Star" in Spring 2010 as a useful (but incomplete) implementation of Perl 6. More details about the features, milestones, and roadmap for this release will be forthcoming over the next few days.


P.S.: Several of our "down-under" community members have pointed out that "Spring 2010" can be a bit ambiguous. I'm using a season (instead of a month) to leave a month or two of wiggle room, but my intention is April 2010. As we get a bit more detail into the plan, we'll identify a specific month.

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.
  • Maybe I'm behind the times and this works, but lately it seems like enough of Perl 6 is there for me to mess around and have fun, except for one thing: I don't think I can do 'make install' and have it in my path, which leads to a few annoying patterns of behavior being required.

    I hope that whatever else you do, we end up with an installable Rakudo.

    Good luck!

    • I'm pretty sure that will be done, because we have a branch for that already.

      If you want to help us, check out rakudo, then run 'git checkout ins2', and follow the usual build instructions. Then tell us if that worked for you, and if you can run a simple Perl 6 program with it (perl6 -e 'say "Hello, world"' or so).

      (I checked that it works for me with an installed parrot, but I didn't try to install Rakudo itself)

      • ~/code/hub/rakudo/parrot$ cd ../parrot_install/
        ~/code/hub/rakudo/parrot_install$ ls
        bin/  include/  lib/  share/  src/
        ~/code/hub/rakudo/parrot_install$ ./bin/perl6 -e 'say "hello world"'
        hello world

        Works. I should look harder at how to have it install to /usr/local, but cool.

        • You'll be pleased to know that the ins2 branch has been merged into trunk, and that the August release of Rakudo can now be installed.

  • 1. If you need wiggle room, use Q2 2010. That's a part of why companies do it.

    2. Naming a release based on an injoke for a new language isn't very engaging or informative.

    • 1. If you need wiggle room, use Q2 2010. That's a part of why companies do it.

      "Spring" had a few other connotations that I liked for my purposes, but your point is well taken. After this week I'll likely just use a month to refer to the expected delivery date.

      2. Naming a release based on an injoke for a new language isn't very engaging or informative.

      * I think "Rakudo Star" probably has enough merits to stand on its own without the injoke.

      * It's really just a "working name" until/if we come up with one

  • well, do not use 1.0 for sure or we might have PR disaster, just like KDE 4.0 (that was release aimed at developers, but being .0 release, many users/reviewers tried it and were very disappointed. afaik fedora labeled and distributed it even as a stable release, so many users were f*d)
  • Give some thought to forward compatability. People will be much more likely to use "Rakudo Star" for real-world applications if they can be guaranteed that the version of the language they're writing to will remain supported after the language evolves in future releases. If upgrading Rakudo will break real-world applications because the language semantics evolved, that will discourage anyone from writing those applications in the first place, especially serious ones that can't necessarily be rewritten eve


    "Simple things should be simple, and complex things should be possible." - Alan Kay

    • I think you're addressing the more practical nature of Perl 6 which still seems premature, as I read this thread. There are applications to be written, libraries to be ported, packages to be bundled, books to be written, training classes to be prepared. Until it syntax/semantics are stable (not necessarily code stable) then it's pretty much impractical to do most of these things. And some have *long* lead-times (books, porting projects). Some can't be undone (releasing an app into the wild). Software h
      • So, riddle me this. What would an adult prefer: shoehorning all software projects into a 6 stage development model, or looking at the dynamics of a community and trying to find a development model that works well and produces the best result? Your stages are mighty fine for a lot of situations, but I'd hate to be as inflexible to think it's the only way to succeed.

  • Here, I'll explain since you don't seem to get it.

    When people ask "When will Perl6 be finished?", they want to know when there will be a Perl 6.0 release. Of course everyone realizes development will still continue, who ever said it wouldn't? The question doesn't imply that at all, at least not to me.

    If you don't want to answer the question then don't. But don't act like it's some huge imposition to be asked.

    As a software developer I'm asked about my ETAs every single day. It's really not that
    • No need to be snarky.

      As a frequent denison of #perl6, the impression I get when this is asked on IRC is the same as what pmichaud finds. Maybe it's not intended that way, but asking is something is 'finished' to me implies 'is the spec completed', not 'is the spec at 6.0', no matter the actual intent.

      Just to add: the folks on #perl6 are very accommodating to new users, including ones that ask that question. It's probably the nicest IRC channel I've been on.

      • I would imagine the people who ask about Perl6's ETA don't care much about the Perl6 spec completion date. It's probably safe to assume they mean when can they do something like `apt-get install perl6`.
        • I would imagine the people who ask about Perl6's ETA don't care much about the Perl6 spec completion date.

          Yes, but the spec and the test suite define what Perl 6 is, not a single implementation. Anything that passes the test suite is considered Perl 6, so Perl 6 can have many implementations. As the article states, having a 'useful Perl 6' will help drive the spec to completion, but it likely won't be the only implementation in the long run.

          It's probably safe to assume they mean when can they do something like `apt-get install perl6`.

          Agreed, and that's the disconnect. It'll probably be something more like 'apt-get install rakudo' or similar.

          • Then why isn't the article called "a useful rakudo"? Why not try and close the "disconnect" rather than perpetuate it?

            Seriously, the Perl6 spec isn't even nailed down yet? What is the hold-up on that? Design by committee?

            Seems like Perl6 might be going the way of GNU/Hurd, eternally under development, and never to land.
            • Then why isn't the article called "a useful rakudo"? Why not try and close the "disconnect" rather than perpetuate it?

              I think b/c it's the only implementation far enough along to get new users interested (and maybe allow them to jump in on other spots NYI).

              Seriously, the Perl6 spec isn't even nailed down yet? What is the hold-up on that? Design by committee?

              Much of the spec is implemented in Rakudo, enough to make it quite 'usable', and Rakudo is passing around 12000 tests. If anything much of the spec has changed due to actual attempts at implementing it, either via Pugs, Rakudo, smop, etc. (the removal of want() comes to mind)

              Again, as mentioned in the article that may be the push needed to flesh out spots in the spec (c

            • I've written a response to this thread in a separate article [].


  • Well, don't wait for user input, just go ahead and finalize sine qua non's like concurrency policy/implementation. Perl6 is already getting lost in the flurry of announcements about new JVM lingos. Something like concurrency support has to be seen as an absolute top priority for any "current" lingo. Perl6 (hopefully) was not conceived of as a nifty-er compiler of digested text reports!
    • That sounds like a design principle guaranteed to make everyone from language designers to implementers to users unhappy with the results.

      What do you want from a concurrency system?

  • I really don't get this argument. It's like, you want a release which you want to advertise to people as ready for consumption, but you don't want to "use up" the 1.0 number delivering something which isn't "finished". Forget the overpromising, it's years too late for that.

    Honestly, no-one will care if the complete Perl 6 is not there, so long as the implementation is good, it's debuggable, you can start making bindings for C libraries easily, and there is an effective module deployment system it should

    • No one cares about “alpha” versions. Look at how much testing even the Perl 5 Release Candidates get: it’s barely distinguishable from none.

      Which is no surprise, and is even less so for alphas. The typical meaning of “alpha” is “we’ve picked a feature set but the features aren’t done yet and we’ve not even started on the bugs” – miles away from production stability.

      That’s not what Rakudo* is about. Quite the opposite: the idea is t

      • And what the heck number are the distribution packagers going to give it?

        It's matching the "Whatever" to the wrong side of the argument. "Rakudo *" to me means the version that a particular person starts using it, not a fixed release.

        Why not just call it 1.0, make it clear to everyone what's finished and what's not, then there is no over-promising.