It may be that even were Perl 6 available right now it would still be wise to stick with Perl 5 for a major project involving a team the presumably hasn't much Perl 6 experience.

It is definitely too soon to start betting on perl 6 since we don't have the actual perl6 compiler yet. Sure there's pugs and if you can live with the reference implementation running on top of ghc and can live with random changes as the language (and implementation) evolve, then maybe you would want to bet on perl6.

Personally, I'm going to wait until there's a real compiler (I figure 2-5 years before we have a compiler that's stable enough for production use)

The cool thing about this is that Perl5 will run on Parrot through a project called Ponie. This means that you don't have to bet on Perl5 or Perl6 because both will be supported on Parrot.

Note that searching for ponie on CPAN returns as its first hit Acme::Pony which is totally unrelated :-)

Personally I prefer ACME::POE:::Knee.
-nuffin
zz zZ Z Z #!perl

http://www.perl.com/CPAN/src/stable.tar.gz

I suppose there's some chance it will be Perl 6.x.x, but I doubt it! More likely you'll get the latest 5.8.x which is working great for me at present.

-sam

Of course there a number of Perl6 concepts already implemented as modules in Perl5: search for Perl6 on CPAN.

You can use perl 5 today much more easily than e.g. pugs, which is definately not a stable platform (albeit lots of fun).

I do suggest you look at, and familiarize yourselves with Perl 6, the pugs project, the synopses, etc, and design something that is easily portable to Perl 6. This is mostly a design issue - Perl 6 has roles, grammars, better support for higher order functions, etc. This means that while some things look equally ugly in Perl 5, one of them might be beautiful and easy to read in Perl 6 - so this could affect your decisions.

Much more important, IMHO, is community involvement and interoperability. If you want this Oak project to work out well, please make sure that:

• You have a publically accessible respository, where people are encouraged to contribute (especially tests and documentation)
• You have an IRC channel and/or mailing list so that people can meet, get help, and group think
• You reuse familiar modules from the CPAN, especially for small mundane tasks, or contribute/replace modules that aren't fitting. Keep things generic!
• Keep things very simple - many CPAN modules are hard to use because of an installation headache. Since Perl is so portable this can actually a pretty tough issue to deal with. This also applies to your interface, but of course you already knew that =)
• Invest some funded hours in the tasks that you are not likely to get volunteers to do, but that are equally important - documentation, high quality tests, etc.

This isn't to say that perl 6 won't exist. It may, it may not, and when it does you may or may not care. Betting a project on another project that is significantly incomplete and whose completion date has a significant amount of uncertainty is just unwise.

This isn't to say you shouldn't use some of perl 6's features, not at all. The perl 6 modules on CPAN all provide interesting and useful functionality, and if you think that perl 6 may be the way you want to go in the end then it'd be sensible to use them where you can, to make transition easier.

Well, considering the 24 months will start counting in the next couple months, I was wondering if it's sane to bet on Perl 6, or if I should stick with Perl 5...

Of course there are other languages too :-)