Perl 6 in 2011 - A Retrospection
perlgeek.de
perlgeek.de
I'm sure you also know that the specifications of Java, C, C++, python, Haskell and other languages are still being developed too.
I'm using Perl 6 "in the real world". I use it on my spare time. I use it at work. I have production code running in Perl 6. I use Perl 5 even more heavily, but with each month I use Perl 5 a little less and Perl 6 a little more.
Seen from ten thousand meters, Rakudo 2008-2010 was about features, and Rakudo 2011 has been about performance. As moritz' retrospective states, the fruits of that work are only coming online now. That will enable more people to move into performance-sensitive fields such as web development with Perl 6. That's already starting to happen; see tadzik's Bailador project, for example.
Meanwhile, my Perl 6 production code has been getting by with slightly lowered expectations on performance and memory frugality. Crashes/segfaults are no longer a problem (as they were in 2008/2009). Tradeoff example: My blog, which runs on Perl 6, is statically generated rather than dynamically. That's been working out pretty nicely.
When I need more speed and/or regex/grammar features, I go with Niecza. Otherwise, I mostly develop on Rakudo. But Niecza's main developer is developing at an almost intimidating pace, and I expect to be using Niecza even more in 2012.
Is there a Perl 6 implementation for any other free VM's (aside from Parrot)? I've heard Lua's is very fast. Or maybe LLVM?
Because going to perl.org -> Download says "We recommend that you always run the latest stable version, currently 5.14.2." [1] and doesn't even mention Perl 6.
And when you do find a page that has Perl 6, it says "If you are looking for production ready code please use Perl 5" [2]
Perl 5 and Perl 6 are two different languages that happen to share a similar style and history. The latest version of Perl5 will never be 6.something.
And yes, Perl6 is not recommended for production use, since the specification has not been finalized. By the same argument, C++0x should not have been, yet many people did.
I see little equivalence; despite the flux of the C++0x specification, many C++ useful and usable compilers existed and implemented several portions of the specification.
Put another way, the draft status of portions of the Perl 6 specification say nothing about whether "Just compile git HEAD yourself!" is the preferred distribution and deployment mechanism, nor about whether the right approach to supporting real users involves slapping a TODO tag on regressions to appease the test suite.
My company was working on a product based on Perl 6 two years ago. We planned to release it to paying customers at the time of the Rakudo Star release. We officially scuttled it several weeks ago when it became obvious that Rakudo's development process would continue to be incompatible with shipping a working product for as far as we could predict (and two of us have commit access to most or all of the Rakudo stack, so it's not like we're disconnected from the development of Perl 6).
The words "useful" and "usable" do not reflect the reality of the situation.
Could you explain what happened to change your perspective?
Certainly. Rakudo Star wasn't what everyone hoped it would be, but I figured another few months of tuning and releases would let it stabilize to the point where our customers could rely on it as a significant part of the product. That was my understanding of Rakudo Star, sort of the Perl 6 version of Debian Testing versus the Debian Unstable monthly compiler releases.
Performance wasn't a huge concern; the five to ten percent monthly improvements we were getting were sufficient for our projections, if they continued. (They did.)
Around December 2010, some of the Rakudo discussion turned to rewriting the main implementation language used to bootstrap Rakudo (and part of the discussion was "Hey, this'll be a great opportunity to consider targeting additional backend VMs!"). Scopes creep and rewrites produce regressions and remove stability.
Rakudo forked its development into "The old stuff that used to be Rakudo Star but won't get any updates or even releases" and "The new branch which will become the main branch even though it won't see any releases and has huge regressions" and they're starting to address regressions now.
As you might expect, the release schedule for Rakudo Star slipped from "every month" to "every three months" to "whenever things get stable".
In the absence of project discipline to release stable code every month--in a culture which believes it's okay to tell people "Sure, it's useful and usable, just track Git HEAD for multiple components"--you can't deploy a product without heroics. I'm not going to risk my business on heroics.
In short, they stopped delivering a stable product and I stopped believing in their ability or their desire to do so.
As an outside observer of Perl 6 development since its conception, I feel that this pattern (Scope creep and massive rewrites / depreciation of current infrastructure whenever one component was in "danger" of becoming useful) has played out over and over again throughout the life of the project.
This went back at least to the original Parrot announcement. Arguably, even the _birth_ of Perl 6 was based on the idea of a massive rewrite, superseding the much more modest Topaz effort (After about two years of development, Topaz had not yet delivered fully working code. The original announcement of Perl 6 promised working code in 18 months).
I normally agree that throwing away working code and starting anew is the wrong approach, but trying to rewrite the Perl 5 internals to support Perl 6 would have taken at least as long as Parrot and Rakudo have taken; it's really that impenetrable in places.
Your phrase "in danger of becoming useful" is quite perceptive though; I wish I'd thought of it.
As a comparison, python.org has both Python 2 and Python 3 binaries clearly marked and available for download.
I'll be surprised if Perl 6 gets much attention until the perl.org download page has links to Perl 6 binaries, like it does for Perl 5 binaries. Visiting the download page, you wouldn't even know Perl 6 exists.
At this point how many companies do you know of that use perl6 to solve their business problem (may be as simple as a web app) ?. Has there been any job posting anywhere which are looking for perl6 devs?
That said, there's two of us in the company I work for: http://www.edument.se/english/ . I got hired mostly on my merits as a Perl 6 core contributor. We're eager to hire more Perl 6 programmers.
Even if one of the projects implements the full perl 6 spec that exists today, there are very few perl 5 devs that will switch over ,If I were asked to guess it would be less than 5 %. Perl 6 as a language has to start at the bottom with other programming languages . The name perl6 was used because one of the reason (I am not sure of this) was to retain the name to get perl5 devs to move to the next version of the language and at that time perl5 was a dominant language.
Another perspective to look at is that perl6 was announced in early 2000 clojure came around 2007 , scala appeared around 2003. There are other languages like go and dart which have google backing that have come out.
So IMHO if you want to learn language design and the other things around it perl6 is a good playground you will learn and easy to get into the community but you will not get a job because of it. If you are a user of programming language who wants to use a language for solving a real world problem today (with libraries and get questions answered) or learn a language which will get you a job you will be better off with perl5 , php, ruby, python, scala, clojure or <insert your lang>
I recall being optimistic that Perl 6 would come out of the oven in 12 to 18 months. Sadly, that was in 2004. My feelings about Perl 6 are like those about a Microsoft OS that is stable, secure and performant: a nice idea that has grown into a myth. Sorry to dump on Perl, I still have many friends who use Perl 5 on daily basis. I think for a lot of folks, the real "Perl 6" is... Ruby.
That doesn't make sense; why would a "real Perl 6" be measurably worse than Perl 5?
That and language stability, ecosystem, internal coherence, library availability, release process, compatibility, deployment concerns, tooling....