use Perl Log In
Building a "useful Perl 6"
"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 STD.pm 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.
Pm
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.
very exciting; one request (Score:1)
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!
rjbs
Re: (Score:1)
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)
Re: (Score:1)
Works. I should look harder at how to have it install to /usr/local, but cool.
rjbs
Two things (Score:1)
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.
Re: (Score:2)
"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.
* 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
Re: (Score:1)
do not use 1.0 (Score:1)
What about forward compatability? (Score:1)
Deven
"Simple things should be simple, and complex things should be possible." - Alan Kay
Perl6 "finished" (Score:1)
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
Re: (Score:1)
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.
Re: (Score:1)
Re: (Score:2)
I've written a response to this thread in a separate article [perl.org].
Pm