<div dir="ltr">On Sun, Feb 10, 2013 at 12:13 AM, Allison Randal <span dir="ltr"><<a href="mailto:allison@parrot.org" target="_blank">allison@parrot.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
[...] But, it has all the baggage of project legacy, reputation, and relations<br>with other projects, without the advantages of existing code.<br></blockquote><div><br></div><div>Publicity wise, it's all in how you spin it: 'Parrot: Resurrection' has a nice ring to it ;). As far as relations with other projects go (we're talking about Rakudo here, right?) - there might have been a bit of badmouthing on IRC, twitter and reddit, but that's ok as long as the people who matter remain reasonable.<br>
</div><div><br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">[...] Yet another grand plan for the architecture is no better<br>
than what we have, if it isn't executed. This isn't an academic<br>
exercise, we don't get points for thinking about cool things. The only<br>
measure of success that matters is real use in the real world, and<br>
Parrot (and Rakudo, and Perl 6) have so far utterly failed by that<br>
standard [...]<br></blockquote><div><br></div><div>13 years ago, no one knew what Perl6 would look like and require in terms of VM primitives. Now we do.<br></div><div><br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

Your quick notes on<br>
<a href="https://gist.github.com/gerdr/48890726c026588535fa" target="_blank">https://gist.github.com/gerdr/48890726c026588535fa</a>, sound like the exact<br>
same things we were saying in Parrot 6 years ago. That's not necessarily<br>
a bad thing, but chances are that different results will only be<br>
achieved by setting different goals and meeting them with different<br>
strategies.<br></blockquote><div><br></div><div>As far as I remember, Lorito/m0 design never went beyond 'This is our new runcore and bytecode. By magic and pixy dust, it integrates with the existing infrastructure'. We need to start with NQP's needs (6model, QAST, regex, serialization) and come up with a good story from that end. 6 years ago, Rakudo internals were in no shape to do this.<br>
<br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
This plan requires substantial buy-in from Rakudo, which they've been<br>
hesitant to give. Maybe they've just been burned in the past, and would<br>
gain enthusiasm as their needs were met. That's a big "Maybe" with a lot<br>
riding on it.<br></blockquote><div><br>I don't really see that problem. The main point of the Rakudo devs is that they don't want to work on or maintain a codebase that has yet to prove its worth. I can't image that they would have anything against someone else doing it.<br>
</div><div><br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
[...] I agree with Brian's comment that focusing on just "Parrot-light" has a<br>
better chance of success than trying to do both that and a re-design on<br>
the "big VM".<br></blockquote></div><br></div><div class="gmail_extra">See my reply to Brian.<br><br>-- gerdr<br></div><div class="gmail_extra"><br></div></div>