Your skill will accomplish what the force of many cannot |
|
PerlMonks |
Patrick's answer to chromatic's Rakudo requirements (was Re^4: Rakudo Star, Red Queen Edition)by raiph (Deacon) |
on Jan 27, 2012 at 16:28 UTC ( [id://950411]=note: print w/replies, xml ) | Need Help?? |
Update. 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: <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 Section
Meditations
|
|