[jlarocco]

"Why wouldn't the current three implementations be angled for real-world use?"

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]

[1] http://www.perl.org/get.html

[2]http://dev.perl.org/perl6/

[bryanlarsen]

When somebody asks you "What's the latest version of C?" Do you answer "C++11"? Of course not.

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.

[jlarocco]

True, but there's no "5" in "perl.org".

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.

[chromatic]

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.

[bryanlarsen]

Despite the flux of the Perl6 specification, many Perl6 useful and usable compilers exist and implement several portions of the specification.

[chromatic]

... many [Perl 6] useful and usable compilers exist and implement several portions of the specification.

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.

[microtherion]

This is rather surprising, coming from you. In past years, you vehemently took the opposite side of that argument (e.g. http://news.ycombinator.com/item?id=1737504).

Could you explain what happened to change your perspective?

[chromatic]

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.

[skyheights]

I love perl6, and though I wish otherwise, I have to agree with this assessment. #perl6 is a resonant echo chamber, but I do admire the people and enjoy reading the logs. Maybe one day...