Thanks for your (relatively) straight answer.

Will that be fixed any time soon?

You don't seem to have noticed that, but the Rakudo Star releases are our attempt at fixing that. The "star" releases aim at providing modules, documentation and stability to the user.

Since the current development branch ("nom") has had quite a few regressions against the old master branch, we haven't made any new star release from it so far (though 4 months aren't that much, compared to the release cycles of many other projects). So people who use the star releases enjoy much more of the stability you seek. We'll take care to make the next star release as compatible with previous star releases as we reasonably can, though of course module authors and end users still have to track spec changes.

You seem to oppose the big rewrites that Rakudo has gone through, though so far I haven't seen you proposing any viable alternatives. I can see how annoying the breakage is that comes with such a rewrite, but we don't do them for fun; we do them because we see no other way to implement large-scale changes that need to be implemented in order to advance Rakudo. What would you do instead?

... we see no other way to implement large-scale changes that need to be implemented in order to advance Rakudo.

I find it difficult to believe that porting 6model to multiple backends is essential to make Rakudo usable for end users in 2011 or 2012. "Fun" about sums it up from my perspective.

What would you do instead?

What any other project would do if it wanted to convince its target audience that it can produce a relevant and usable product: ask them what they need, then make it so.

What I want: libraries, documentation, stability, regular improvements on a fixed schedule, and protection from Morton's fork with regard to choosing between running an abandoned old version or getting performance improvements at the cost of severe regressions.

Perhaps that means making something like Blizkost work (and keeping it working) instead of checking off tickboxes like "auto-parallelizing metaoperators" and "custom operators" and "hygenic macros".

I find it difficult to believe that porting 6model to multiple backends is essential to make Rakudo usable for end users in 2011 or 2012.

And none of the Rakudo core hackers spent significant amounts of time on that. Jonathan prototyped 6model in C# because he felt it was the fastest way to do it. He did spend maybe half an hour or an hour helping diakopter to port it lua.

I don't see why you continue coming back over and over again to the little extra amount we spend on investigating cross-VM compatibility; it really makes less than 5% of our hacking time, probably much less.

What any other project would do if it wanted to convince its target audience that it can produce a relevant and usable product: ask them what they need, then make it so.

And that's exactly what we did. After the first Rakudo Star release, we got huge amounts of feedback, and the first thing that nearly everybody wanted was more speed. That's a big reason for 6model -- you simply cannot make Rakudo efficient on top of an object model that requires several elements that the GC needs to consider, just to construct a very simple object with one integer attribute. And you can't make it efficient if the object model doesn't support gradual type.

That's the reason mean reason for 6model and the nom branch of Rakudo, and it does work. Every program that I've benchmarked so far is much faster on nom than on the old master branch.

So, we listened to our users, and we did what the users asked us to do.

Perl 6 - second systems done right