. I screwed up in this chat. chromatic explains that I completely misrepresented his position. See this post
for the details.
Patrick Michaud (a leading dev of Rakudo, a leading Perl 6 compiler) was kind enough to provide his response to chromatic's "list of requirements to use Rakudo for practical purposes" inasmuch as they applied/apply to Rakudo Star.
I've edited out some stuff I consider unnecessary. Here's what's left:
10:14 <pmichaud> #1 (work on future releases) Rakudo Star was intended to support that to the degree that the Perl 6 language would support it. If the language changes significantly, there's not much Rakudo can do about that short of providing some sort of release cycle for code migration
10:14 <pmichaud> #2 (tied to one release) I think that question is more about other implementations than Star itself; but no, Star has never been intended to be its own walled garden of Perl 6
10:15 <raiph> #1 but what about regressions due to other factors?
10:15 <pmichaud> Star was intended to avoid regressions, yes; but it didn't work out that way.
10:16 <pmichaud> I think jnthn++ (and I) really underestimated the degree of regression that would be involved. But I'm not sure it could've been helped either.
10:16 <pmichaud> The alternative would have been to not release any form of Star at all, I think.
10:17 <pmichaud> #3 (library guarantees of reliability) Yes, we were hoping to provide a stable platform for library development.
10:17 <pmichaud> #4 (stuck on cycle of monthly upgrades) Star was explicitly intended to enable people to break the cycle of monthly upgrades, by providing standard checkpoints.
10:18 <pmichaud> Again, there were some problems there, but not entirely Rakudo/Star's fault (Parrot made some significant changes that we had to react to and that caused some babysitting)
10:19 <pmichaud> #5 (abandon code due to compiler rewrite) I can't say what Star intended here. We wanted to have a more consistent platform, yes; but again, much of the changes in the new implementation were due to language requirements and not a capricious "oh let's rewrite the compiler again"
10:20 <raiph> chromatic summarizes that he said in dec 2010 "don't do nom, not needed, will take too long".
10:21 <pmichaud> I disagree with the "not needed part", vehemently. We had to rewrite the object model.
10:21 <pmichaud> What we had in Star at the time was completely inadequate for long-term growth.
10:22 <pmichaud> And the politics of the time meant that there wasn't a way to get crucial object model changes into Parrot in a timely fashion.
10:23 <pmichaud> it's been a hot-button issue for him, certainly. I have a great deal of respect for chromatic, and generally agree with him in most respects, but this has always been a place where we've had to agree to disagree.
10:23 <pmichaud> I don't think he's wrong about the negative impacts of doing nom; I just don't see what we could have done differently.
10:24 <raiph> right. so here's a key thing: would you say the rakudo project committed to anything?
10:25 <pmichaud> we committed to getting some form of official release in July 2010, and have a regular release cycle after that.
10:25 <pmichaud> But Star was never intended to be the end product, no. It was the next stage of development.
10:26 <pmichaud> (we didn't necessarily plan on a full compiler rewrite, but that's effectively what ended up happening. Again, it was what made sense at the time)