SPPN

Stichting Perl Promotie Nederland

Nieuws

Volgende Vorige

8 augustus 2009: Rakudo - Building a 'useful Perl 6'

By brian_d_foy

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.

For more information: http://use.perl.org/comments.pl?sid=09/08/07/046239.

14 april 2010: Perl 5.12 gereleased
1 december 2009: Bestuurswisselingen
8 augustus 2009: Rakudo - Building a 'useful Perl 6'
17 januari 2009: Aankondiging zesde Nederlandse Perl Workshop
22 december 2008: Perl ontwikkeling overgezet naar Git
16 december 2008: Perl 5.8.9 is uit
11 december 2008: Booking.com donates to The Perl Foundation
12 november 2008: Test je programma's met 5.8.9 RC1
11 november 2008: David Mitchell krijgt TPF grant voor Perl 5.10.1
18 december 2007: Perl 5.10 gereleased op Perl's 20e verjaardag
7 december 2007: Aankondiging vijfde Nederlandse Perl Workshop
16 november 2007: Perl 5.10 RC1
3 september 2007: SPPN sponsort Perl6 ontwikkeling
30 augustus 2007: The Belgian Perl Workshop 2007
16 maart 2007: Camel Trophy voor H. Merijn Brand
6 februari 2007: First European Perl Hackathon
31 januari 2007: Aankondiging vierde Nederlandse Perl Workshop
17 mei 2006: Uitreiking Camel Trophies
26 januari 2006: Aankondiging 3e Perl Workshop
20 oktober 2005: Camel Trophies
1 oktober 2005: Veel Perl op de NLUUG conferentie
1 september 2005: Perl Roadmap
15 april 2005: NLnet sponsort ontwikkeling Parrot
25 februari 2005: Eerste Camel Trophies uitgereikt
10 december 2004: SPPN Steunt aktie tegen monstercontract Overheid
29 november 2004: Nederlandse Perl Workshop 2005
19 november 2004: Wijzigingen in het bestuur
8 juli 2004: Perl Roadmap

Stuur een bericht