Or at least lay on more. Here's the scoop--we need a Perl 6 pumpking, someone to take on the responsibility of making the Perl 6 compiler happen. When we started this whole process these many years ago, we though having one person handle the software end of things was sufficient, but making perl 6 a reality is a much larger task than we'd originally figured, as both Perl 6 the language and Parrot the interpreter have ended up bigger than we'd thought they'd be. Bigger, in fact, than one person can reasonably manage, especially with a volunteer project.

Hence, the call. Got people skills? Can you organize? Competently design code? Got free time? Work with people who are, well, Larry? Cool, this is for you. You don't have to be a star programmer, nor a parser or compiler whiz, though that certainly won't hurt. Enthusiasm's what you need, as there are people willing to help you out with the rest.

There are plenty of things you don't have to worry about. You don't have to worry about the language design--that's Larry's job. Nor do you have to worry about the interpreter engine--that's Dan's job. What you'll have to do is get the Perl 6 compiler module, and its standard library, designed and implemented.

It's a big job, but someone has to do it, and that someone could be you. (As a bonus, you get your own Secret Perl Cabal membership card and Decoder ring!) If you're interested, make your pitch to our esteemed, and mostly sane, Perl 6 manager-type person Allison Randal, at

Good luck!

Replies are listed 'Best First'.
Re: Time to change the (Perl 6) guard!
by dragonchild (Archbishop) on Jul 06, 2004 at 17:40 UTC
    I'd be very interested in helping with certain portions of it, but I don't have time to take over the whole project. Would it be possible to get a few people to take over certain portions of the design from you and you stay on as an overseer?

    We are the carpenters and bricklayers of the Information Age.

    Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose

    I shouldn't have to say this, but any code, unless otherwise stated, is untested

      Unfortunately not--this is really an all-or-nothing sort of thing. Not because I don't want to do any of it (that's entirely beside the point...:) but because the job I really need to pass on is the coordinating one.
Re: Time to change the (Perl 6) guard!
by gmpassos (Priest) on Jul 07, 2004 at 08:11 UTC
    I think that you should invest some time in documentation of the project it self, what will be much more easier to integrate new developers to the development of Parrot (in any area of the project, not only the VM or Perl6).

    Today if someone get the Parrot source it doesn't know what does what, and how to work in something that it want to add or fix, and bingo, you lost some potential developer. If understand the project be a intuitive thing, we can work faster in the exactly point that we need.

    For example, get the Perl5 sources, we have a lot of .c files, directories, libraries, specific OS versions, etc... But we doesn't have a main document that exaplain what is what in the source tree! Will be much more interesting to have in the top of each .c file of the Perl CORE, some text that says, this files is for bla bla bla. We also should have some list of the pourpose of each directory of the distribution, like know that ./ext are the modules that need to be compiled, and ./jpl is just a sub project that integrates Perl and Java, etc...

    For who knows Perl and hack it this is silly, we think that is easy to "hack" and look all the sources. Well, for someone that work with Perl for years, yes, is silly. But let's say that you got Perl today, for the 1st time, and want to add/change/play with the sources? A good documentation will be good, and this is what we need to do with Parrot, be able to play easier with it just from the 1st time.

    Graciliano M. P.
    "Creativity is the expression of the liberty".

Re: Time to change the (Perl 6) guard!
by BrowserUk (Pope) on Jul 12, 2004 at 18:35 UTC

    It's a real shame that there doesn't appear to be any way to harness the strength-in-breadth and contribution rate of PM to bolster the ranks of P6 development.

    Examine what is said, not who speaks.
    "Efficiency is intelligent laziness." -David Dunham
    "Think for yourself!" - Abigail
    "Memory, processor, disk in that order on the hardware side. Algorithm, algoritm, algorithm on the code side." - tachyon
      This is one of those places where breadth doesn't buy you much by itself. It can be useful, but only as an adjunct to the depth.

      You don't, however, need that depth to manage the project, and it's relatively easy to pick up what you need along the way...

Re: Time to change the (Perl 6) guard!
by Anonymous Monk on Jul 07, 2004 at 13:01 UTC

    The cabal does not easily accept new members, and the decoder ring comes in only one size.

      Cabal? What cabal? There Is No Cabal. And if there was one, it could cope. Hell, if it existed it would've coped with me for years.

      Nobody wears the decoder rings anyway, they're too gaudy and they turn your finger green. Best to keep it in a box for emergencies.

A reply falls below the community's threshold of quality. You may see it by logging in.