[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.

[microtherion]

Thanks, that is a very clear explanation!

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).

http://use.perl.org/~masak/journal/40451

[chromatic]

Parrot and Perl 6 really suffered until Pugs started producing a standalone test suite. If Perl 6 on Parrot had had that in 2000 or 2001, things might have turned out differently.

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.

[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...