On 02/09/2013 11:37 AM, Gerhard R. wrote: > Assuming there's still sufficient interest, I propose the following > steps as a way forward: > > 1. Fork off a Parrot-light with the sole purpose of supporting Rakudo > > 2. Start design of Parrot2
If there's a group of at least 3 (preferably 5 or more) developers inspired by your vision, and willing and able to devote the time required to complete it, they certainly have my blessing to use the Parrot name (to whatever extent I have a blessing to give, as one of Parrot's many contributors). I'd be thrilled to see it. I've considered something similar at several points over the past few years, but always set it aside as I realize I really don't have time. I do have some reservations, however. Maybe you have easy answers to them, I don't. Please don't take this as discouragement, it's an encouragement to really see the full challenge and step up to it. - Restarting a project from the ground up a dozen years in, with no "production" releases and no "production" users, is a risky business. Not impossible, certainly. But, it has all the baggage of project legacy, reputation, and relations with other projects, without the advantages of existing code. This might be alleviated by doing the work under the "Rakudo" banner rather than "Parrot", or declaring them as one and the same. (This would mean that the "existing codebase" you keep is Rakudo, and the work is a matter of replacing the bits of Rakudo provided by the current Parrot with new bits more tailored to its needs.) - Parrot's problem isn't "architecture" in the sense of design, it's the fact that none of the series of designs for it have ever been fully implemented. 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 (token use by a handful of people who participate in the projects anyway doesn't count). Again, it's not impossible, but it is very difficult. - 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. - 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. To end on a high note, I do firmly believe that "lighter and faster" is the only way Parrot can succeed, and this plan has that going for 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". Allison _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
