The Parrot is dead. Long live the Parrot?

kjstol parrotcode at gmail.com
Mon Feb 11 22:25:30 UTC 2013


On Sun, Feb 10, 2013 at 3:03 PM, Gerhard R. <gerd.r.devel at googlemail.com> wrote:
> On Sun, Feb 10, 2013 at 12:13 AM, Allison Randal <allison at parrot.org> wrote:
>>
>> [...] But, it has all the baggage of project legacy, reputation, and
>> relations
>>
>> with other projects, without the advantages of existing code.
>
>
> 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.
>
>
>>
>> [...] Yet another grand plan for the architecture is no better
>>
>> than what we have, if it isn't executed. This isn't an academic
>> exercise, we don't get points for thinking about cool things. The only
>> measure of success that matters is real use in the real world, and
>> Parrot (and Rakudo, and Perl 6) have so far utterly failed by that
>> standard [...]
>
>
> 13 years ago, no one knew what Perl6 would look like and require in terms of
> VM primitives. Now we do.
>
>
>>
>> Your quick notes on
>> https://gist.github.com/gerdr/48890726c026588535fa, sound like the exact
>> same things we were saying in Parrot 6 years ago. That's not necessarily
>> a bad thing, but chances are that different results will only be
>> achieved by setting different goals and meeting them with different
>> strategies.
>
>
> 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'.

For what it's worth, there was >almost< a M1 compiler (targeting M0)
with C-like syntax that actually ran. A few (2?) interested people
could fix this I'd say. A good start for Parrot2.


kjs


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.
>
>
>> This plan requires substantial buy-in from Rakudo, which they've been
>> hesitant to give. Maybe they've just been burned in the past, and would
>> gain enthusiasm as their needs were met. That's a big "Maybe" with a lot
>> riding on it.
>
>
> 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.
>
>
>> [...] I agree with Brian's comment that focusing on just "Parrot-light"
>> has a
>>
>> better chance of success than trying to do both that and a re-design on
>> the "big VM".
>
>
> See my reply to Brian.
>
> -- gerdr
>
>
> _______________________________________________
> http://lists.parrot.org/mailman/listinfo/parrot-dev
>


More information about the parrot-dev mailing list