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:
<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
<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
<raiph> #1 but what about regressions due to other factors?
<pmichaud> Star was intended to avoid regressions, yes; but it didn't work out that way.
<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.
<pmichaud> The alternative would have been to not release any form of Star at all, I think.
<pmichaud> #3 (library guarantees of reliability) Yes, we were hoping to provide a stable platform for library development.
<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.
<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)
<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"
<raiph> chromatic summarizes that he said in dec 2010 "don't do nom, not needed, will take too long".
<pmichaud> I disagree with the "not needed part", vehemently. We had to rewrite the object model.
<pmichaud> What we had in Star at the time was completely inadequate for long-term growth.
<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.
<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.
<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.
<raiph> right. so here's a key thing: would you say the rakudo project committed to anything?
<pmichaud> we committed to getting some form of official release in July 2010, and have a regular release cycle after that.
<pmichaud> But Star was never intended to be the end product, no. It was the next stage of development.
<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)
In reply to Patrick's answer to chromatic's Rakudo requirements (was Re^4: Rakudo Star, Red Queen Edition)
by raiph
in thread Hockey Sticks
by raiph
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |