-sam

If you need stuff now (i.e. this year), use existing tools. There is always going to be something newer or shinier in the future, so don't put things off because something cooler is due Real Soon Now.

Perl 5 is not going to suddenly disappear. It will still do all the things it did before. If you're like most people, you'll end up re-writing your application anyway. If Perl 6 is around you can use that then.

Good luck :)

Perl 6 is all about Doing It Right, so has no external deadlines. It's a good idea not to rely on it, as it's already blown past timelines people have estimated for it. It's not someone's job to hit a date, and quality is (correctly) the chief concern, so it's hard to predict when it'll be ready.

But, I would recommend making your design modular where possible, so you can port it over piecemeal when Perl 6 is ready. It's a design goal to be able to run Perl 5 and Perl 6 modules together, and you can rely on that.

All of us Perl Developers who are not Developers of Perl wish Perl 6 were ready sooner - but we're glad we don't have to pay the price of corners being cut to hit someone else's date.

How many "requisite CPAN modules" do you need in Perl6, and how complete does it have to be overall, before you can implement what you want in it? And how stable do you need it to be. If Perl6 (e.g., Pugs) is *close* to being able to do what you want, you could consider starting in Perl6 now, and helping to fill in the gaps.

But, as others have said, if Perl6 is nowhere near being able to do what you want now (e.g., you've got a list of eight CPAN modules you need, some of which have dozens of other CPAN modules as dependencies, or you really need the kind of stability and performance that only come after a year-long feature freeze), then use Perl5 now -- but try to write nice clean modular code so that individual parts of it can be migrated one at a time to Perl6 later, (leaving the remaining parts as Perl5 code, via Ponie or whatever).

It is quite possible to run parts of your application as Perl 5 and parts as Perl 6 today - it's quite possible to use the existing Perl 5 modules as a working "framework", and write all the "application logic" in Perl 6.

You can achieve this in many ways; probably the more mature option right now is to use the use perl5:Foo; interface (ie, use the Perl 5 modules from Perl 6).

There is also the less mature route of compiling Perl 6 to Perl 5; however you'd have to stay away from "eval" and friends if you want that to be production ready this year.

$h=$ENV{HOME};my@q=split/\n\n/,`cat $h/.quotes`;$s="$h/."
."signature";$t=`cat $s`;print$t,"\n",$q[rand($#q)],"\n";
[download]

If you really need it production ready in 6 months, of course you should use Perl 5. However, one alternative to all the suggestions made so far is to use the (not quite yet ready for production) Perl6::MetaModel which myself and a few others on the Pugs project are currently building.

It is basically an implementation of the Perl 6 object meta-model in Perl 5. It will eventually serve as the basis for the Perl 5 runtime when we complete the Perl 6 -> Perl 5 compiler. However, there is actually no reason you cannot use it outside of that compiler as a regular Perl 5 class builder. At the very least it makes it possible to design your Perl 6 classes in Perl 5, and be prepared for the shift to Perl 6, while still having runnable Perl 5 code.

Like I said, it is not ready for production, but it does have a good size test suite which has +90% code coverage (however, this stat is only useful for refactoring the metamodel itself as many corner cases surely need to be tested (and many too need to be coded)). Contributions to the test suite are very welcome, and contributions/comments and suggestion on the overall design are also welcome.