It will be sensible to use Perl 6 to build real-world apps in ...
Let's try to predict when we will be able to {conveniently,realistically,sensibly} use Perl 6 to build real-world applications. Note: this post is just the result of its author's pondering and is not meant to be negative towards Perl 6.
The big challenge is to predict when a Perl 6 implementation will be production-ready. Ironically, although Perl stands for Practical Extraction and Report Language, the development of Perl 6 has become an ambitious and totally impractical project with no set deadline. Its goal is to be a programming language viable for the next 50 years. That's solving tomorrow's problems, problems which might not exist yet today.
The spec has been developed for over 12 years. It's rather stable now, but is still missing some big parts like concurrency, threads, nonblocking I/O, advanced macros. I guess many people is already content with the current spec, so let's say that the spec is more or less done.
Parrot is almost 12 years old but Rakudo on Parrot is hopelessly slow and is probably being abandoned. Unfortunately, Rakudo on JVM will not be a feasible platform for many applications, so even if Rakudo on JVM is production-ready, Rakudo will still need to be available on an alternative platform for cases where JVM is not appropriate.
Let's say we give it 6 years, which is rather optimistic. That means in 2019 we will see something like Rakudo Star 1.0 (the current Star releases don't count, I'm just reusing the name here).
Before 2019, we can already attempt to test Perl 6 for our applications. But realistically, one will not fully invest one's time and energy on a platform that is not labelled production-ready. So we can say that early adopters will only start writing Perl 6 for real in 2019-2020.
We must also realize that Perl 6 is a big language. Mastering and becoming fluent in it requires a significant amount of time. Perl 5 veterans will probably be able to be somewhat conversant in Perl 6 in a matter of weeks, but programmers coming from other languages will take months or a year, at least.
Some of the major/important libraries will also need to be fully mature first so we are confident that our applications will be quite stable. Things like DBI, LWP, Log4perl/Log::Any, Dist::Zilla, Mojolicious/Dancer, and several/dozens more, depending on your application. This process will take years and will involve at least one rewrite for many of the projects. I suspect the typical scenario will be: quickly port something cool from Perl 5, then after the code and API stabilize in about 1-2 years there will be a v2 project to make it more Perl6-ish, because the first version does not utilize hyperop/junction/multiple dispatch enough, or does not have cool DSL that utilizes Perl 6 grammar capability, or whatever. An application developer will have to endure this period with some amount of pain, and will have to perform some amount of rewrite himself/herself. Let's say all of this in 4 years.
Another process that will take years to develop is the best practices (the equivalent of PBP for Perl 6). Unless Damian is already underway in writing this.
Oh, and I bet Perl 6 grammars will encourage the flourishing of many DSLs for various tools/frameworks, like in Ruby with Chef, Puppet, Cucumber, etc, except even more so because grammar-based DSLs will be so much cooler. This is not bad in itself, but all of those DSLs will have to be learnt by developers. So I'll add an extra 2 years for this.
All in all, I think we can start writing Perl 6 for real-world apps in about 2027 at the earliest. I can start earlier, but the thought of having to endure several rewrites during the era of library rewrites and underdeveloped best practices and lack of tools, discourages me.
Unfortunately, by that time, my programming career will be almost over. So I'm sorry Perl 6, I'm afraid I can't afford you.
A programmer (mostly Perl 5 nowadays).
My CPAN ID: SHARYANTO. I'm sedusedan on perlmonks. My twitter is stevenharyanto (but I don't tweet much). Follow me on github: sharyanto.
It's hard to predict. Perl was built to satisfy a real need, twice -- sysadmin work and CGI programming. Perl 6's great weakness is that it is not being designed to solve some immediate problem. If it finds one, it could be ready in a year or two. If not, maybe never.
Heh. Epic fail. :P
Perl 5 (the language and the interpreter) has had known major issues since BMWS (Before Mugs Were Smashed). I'm not aware of any major technical problem with Perl 5 that the Perl 6 design does not address. These are today's (or yesterday's) problems (at least within the Perl community).
Perl 6 also addresses a host of other contemporary and near term future issues in computer languages such as straightforward Unicode grapheme handling and baby parallelism.
Many features in these categories (eg junctions with auto threading semantics, hypers, gather/take, hygienic macros) are not only spec'd but also implemented.
Missing parts are generally small and/or non-essential, and the parts that are both incomplete and essential (primarily non-blocking IO) are very likely to be properly addressed this year. Sure this is incredibly late, but this is due to circumstances (mostly Parrot) beyond the control of the Perl 6 team and it is now finally being addressed.
(Fwiw I thought at first that you meant 6 years to the point that Perl 6 is more solid than Perl 5 pretty much across the board. That's optimistic in the sense that all sorts of things could slow Perl 6 between now and then, and is a tad optimistic even if all goes well.)
I think it'll be the other way around.
Imo baby Perl 6 will be easier to pick up and understand than baby Perl 5 once suitable doc, tutorials, etc. are in place.
Perl 5 veterans will likely know Perl 5 and programming deeply, so many will take a relatively long time to, on the one hand, unlearn and relearn how some basic pieces work (using "." instead of "->", automatic dereferencing, etc.) and, on the other, learn Perl 6 deeply enough that they feel comfortable labeling themselves "conversant".
In 2009 I publicly suggested Perl 6 would be ready for non-contributing mainstream coders in late 2014. I've been reading the entire #perl6 log daily for the last 18 months and I still think that guesstimate is about right.
Given how you view things, your conclusion makes sense.
I'm curious about where that leaves you. Are you thinking you will stick with Perl 5 for now? For good? Switch to another language at some point? Javascript? Haskell? K? Help develop a new Perl 5 toolchain? What are your options?
Hi raiph,
Thanks for commenting and contacting me earlier about your comment. And sorry for mistyping your name (I've almost always read it as raLph).
Yup, you're right. Of course one of the main goals of Perl 6 is to address Perl 5's shortcomings and to be practical to use today. I guess the main concern with most people is the extra goal of being a programming language for the next X years, and the lack of deadline in its development.
Sorry, my bad. I was reminded by Rakudo [Star] release notes when I wrote the blog post, and haven't checked with the synopses/spec. The release notes do mention advanced macros/threads/concurrency as missing items.
Maybe you're right, although you might underestimate Perl 5 veterans here. I'm sure most veterans dabble in other languages too like JavaScript at the very least, so I don't think they will have too much difficulty replacing "->" with ".".
Also, I'm not very keen of having only the ability to speak only baby Perl 6 when developing real-world apps.
Well, we'll see how it goes. But since we're talking about doing "real-world apps" here, like writing something like Movable Type or cPanel, or powering sites like Booking.com or Net-a-Porter.com, I think you still need to realistically give a few more years. As I said in the blog post, in addition to the language+compiler/interpreter themselves, it will take a considerable amount of time to reach maturity levels for all the major toolchains/modules/frameworks/best practices that will be used.
Perl 5 has served me well so far. There are also certainly many other choices where all the toolchains/frameworks/modules/community have matured and are ready to be learned and use *right now* if I want. Perl 6 is certainly not among them. No matter how great Perl 6 is/will be, it will be completely foolish to wait for all those to be ready if you want to develop some products for the present time.
BTW, I just realized that the blog post's title is mangled. Should've been: "It will be sensible to use Perl 6 *to write* real-world apps in ..." Sorry.
The only three things I'm aware of that involve a predetermined timeframe for particular P6 pieces are:
1. Larry Wall's declaration about a year ago that the project needed to "productize" P6 (easy install, decent doc, debugger, modules, support channels) in "a year or two".
2. jnthn's goal to have Rakudo running on the JVM, and hopefully showing some much better benchmark numbers, by yapcna, June 3rd.
3. Larry Wall's recent revelation that he's writing a Perl 6 equivalent of the Camel which he hopes to publish this year.
That surprises me.
I'd appreciate knowing which file says they are missing.
Those features are (imo rightly) tagged as "not-quite-there" in the release notes I've seen (such as the docs/announce for the Feb 2013 Rakudo Star). And while the feature matrix shows some of these as "not yet implemented", that doesn't cover design work (much of the concurrency design was worked out years ago), and doesn't mean implementation hasn't started, just that there isn't sufficient user facing fruit to make it reasonable to display "partially implemented".
I think there's some misunderstanding.
Why would you only speak baby Perl 6?
For starters, ignoring the tweaks that you suggested are not a big deal (eg "." for "->" or invariant sigils), a lot of Perl 5 syntax works unchanged in Perl 6.
And then there's a huge range of useful Perl 6 features that are beyond baby Perl 6 toward which I would expect you to quickly and naturally gravitate.
Right. (I'd say the P6 perspective is akin to "please go learn them if you have the time and inclination" because we want what is learned to feed back in to the evolution of Perl. Several sixers have learned dozens of languages.)