The most obvious thing that could go wrong is of course that the joke is reversed; that the release is after
Christmas, but (perhaps) before lunch.
No doubt there will be a lot of Perl 5 people kicking tires and
checking the look and feel of the shiny new Perl 6, when it hopefully will be
released before this
We've peeked at this years Christmas Present before
, but back then, in 2010,
it was really a prototype; the engine wasn't running properly, the fuel
consumption was horrible, and the dashboard was more or less only for
looks. Some people were disappointed
and left, and the World just kept
on doing what Worlds do.
Other people (e.g. dagolden
) has given their opinion and rasised concerns. I'm excited about much the same things as dagolden, and also (and most) that Perl 6 is built from the ground up, based on a formal design, with the possibilty to evolve many years into the future. Backwards compatibilty is a big win for any language, but so is evolving. Somewhere in the future maintenance of Perl 6 there ought to be a depreciation policy, even for core features that may look cool now, but don't hold up over time.
Perl 6 should be a new baseline for Perl, so to speak. Something that can evolve over many years to come. I hope that performance and memory consumpion from the outset will be on par with Perl 5 with possibility to improve. Also the language itself can improve
. The subset that didn't make it into the gift wrapped box for the first 6.release seems to me to be well chosen. Most of these features will be really cool when they arrive, but when dipping your toe in the language sea, some of the features are natural to look at later.
I'm not concerned about Perl 6 being a big language. Big languages are there to help solve hard problems easily. So what if the average, or even mediocre, developers choose Go in the future. Right now they go to .Net or php. I want a toolkit that helps me solve what I'm about to do. Perl 5 has been that tool for many, many years. I'd like an upgrade, for sure, but if Perl 6 is not that, I'll happily stick to Perl 5.
concerned about the number of really useful modules, and I'm especially concerned about the Perl Toolchain. Recently I searched for discussions revealing what is supposed to happen with the toolchain. Nothing really solid came up, and the current list of modules on one page won't really cut it for professional use. I don't know about Panda, but the issues dagolden raised back in February were deep and scary. Would Perl 6 throw away 20 years of CPAN knowledge? How to build a toolchain for professional use?
's blog came at just about the right time. We need a strong, Perl 5 inspired toolchain for Perl 6. Hopefully not a direct port of the Perl 5 toolchain, but a similar solution to the same problem, taking Perl 6 into account. Perhaps we'll finally get rid of external tools, like make.
Will somebody help jdv? I really hope. I can't; i don't have the time. Any time I can use on looking at Perl 6 would be spent on porting some of my Perl 5 modules. I can do some of that right now (except for the lack of tuits, round or any other shape), but for most, there are yet unmet requirements. I won't get far without
- Databases. Right now, I think DBlish is the best bet. Perhaps because I did a minute amount of hacking on it back in 2010. Perl 6 also needs some kind of DBIx::Class equivalent. Not a direct port, bu something more Perl 6-like.
- PSGI, so I follow Sterling Hanenkamp's quest into P6SGI with great interest. Of course, somebody has to write some middleware.
- HTML Templating. There are some, but I'm getting used to the inheritance system of Text::Xslate
- Something like Web::Machine.
- ... and lots more, of couse. Date and Time handling, email, config files, input validation, serializers, etc. All the things that we have come to take for granted in Perl 5.