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 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.
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!
Re:very exciting; one request
moritz on 2009-08-05T20:35:42
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:very exciting; one request
rjbs on 2009-08-05T20:54:55
~/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 worldWorks. I should look harder at how to have it install to
/usr/local, but cool. Re:very exciting; one request
moritz on 2009-08-20T08:32:58
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.
Re:very exciting; one request
rjbs on 2009-08-20T11:13:22
Awesome, Perl 6 is done!
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:Two things
pmichaud on 2009-08-06T05:29:49
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 we like better.
* I'm not sure that designations really need to be very informative at this stage -- we could've just said "Rakudo X" or "Rakudo n", but I personally find "Star" a bit more engaging than those.
* I think it's least as engaging or informative as names like "Longhorn", "Dapper Drake", "Leopard", "Tiger", etc. Perhaps you disagree with those names also, but clearly there's already a precedence and tradition for this sort of thing by some well-respected organizations.
Thanks!
Pm
Re:Two things
ysth on 2009-08-06T07:15:48
Makes me think "rising star"; not a bad thing at all.Re:Two things
cosimo on 2009-08-08T19:13:15
Rakudo Genesis?
Re:What about forward compatability?
clintp on 2009-08-12T16:37:17
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 has stages: Dev, Alpha, Beta, RC, RTM and Release. We're all adults here, call it what it is. It's still very much a development product.Re:What about forward compatability?
revdiablo on 2009-08-13T21:27:02
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.
Re:Perl6 "finished"
cjfields on 2009-08-07T22:03:38
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:Perl6 "finished"
gdonald on 2009-08-07T22:37:27
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`.Re:Perl6 "finished"
cjfields on 2009-08-08T03:33:43
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.
Re:Perl6 "finished"
gdonald on 2009-08-08T16:06:32
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.Re:Perl6 "finished"
cjfields on 2009-08-08T18:06:04
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 (concurrency for instance) that need real-world use cases as examples. I've already started coding some stuff using Rakudo myself, and have contributed code. It's very nice, just slow (and that should improve soon).
Seems like Perl6 might be going the way of GNU/Hurd, eternally under development, and never to land.
Nah, I think it will eventually reach a 'stable' specification version (with updates after that). Seems to be enough interest to push it there.
Re:Perl6 "finished"
pmichaud on 2009-08-09T02:27:46
I've written a response to this thread in a separate article.
Pm
Re:tortoise loses to hare due to lack of concurren
chromatic on 2009-08-17T05:01:13
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 be great.
Why not start calling each release from then 1.0alpha1, 1.0alpha2 etc, until the major kinks are ironed out.
Well, anyway, just another pot-shot from the sideline.
Re:Why not just use alpha, beta, etc
Aristotle on 2009-08-27T08:29:33
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 that it’s aiming for production quality, but the feature set is limited. In some sense it’s the inverse of an alpha. The point of the product naming exercise here is to communicate to people that they can use this without fear that their working code will suddenly blow up in weird ways due to bugs and “under construction” signs in the language and runtime: “it’s good enough to entrust it with real work”.
And because the limitation of this product is not in the degree of completion of the features, or the rate of bug discoveries (as in a beta), but rather the extent of the feature set, then it becomes completely arbitrary to draw a line between what’s (quasi-)alpha and what’s not.
So from several perspectives, calling it an alpha doesn’t make much sense.
Personally I think this choice of name was really smart.
Re:Why not just use alpha, beta, etc
mugwumpjism on 2009-08-31T22:50:57
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.
