The Parrot is dead. Long live the Parrot?

Jon Gentle parrot at atrodo.org
Sun Feb 10 15:22:14 UTC 2013


I'll add my 2c, for what it's worth.

I've always been a big fan of the idea of parrot, from the April fool's
joke become real to today.  The reason being is because the programming
languages I've been most comfortable with haven't always been the popular
ones, most pronounced has been my prefrence of pascal over c.  I've always
dreamed about a programming world where I could effortlessly program in my
language of choice and have the benifit of the work that others have done.

That being said, I too think that we really need to focus on what Parrot's
goal and direction is: language interop.  Parrot's direction has been too
scattered in my opinion. Are we a compiler toolkit?  I don't think so, nqp
is very perl specific, existing languages will likely use their own tools
and personally, I find nqp dense and not very friendly since you have to
learn perl6 to be able to create a new language. (As a side note, I'd love
to see a compiler toolkit based on winxed)  Plus, a lot of other compiler
toolkits exist out there that do it better, like PyPy, and to an extent,
LLVM.  So, does that mean Parrot is the VM for Rakudo? I think what I've
read in #perl6 in the past few days shows me that the most vocal people
working on #perl6 believe even if Parrot worked, they would rather quit
working on Rakudo than work with Parrot again.

Since we're not a compiler toolkit, and we're not a VM for one language, I
think we need to focus on being a VM for all languages, one that makes it
easy and trivial to run multiple languages at the same time, all as first
class citizens.  Because I believe that if Rakudo runs on JVM, it's at best
a second class citizen, always subservient to Java.

It's actually been my intention for the past six months or so to start a VM
project from scratch, with a focus on language interop. I haven't had time,
nor do I expect to have the time soon, to undertake this project on my own.
 The current idea is based on my Lorito prototype (
http://github.com/atrodo/lorito ) with a couple major changes.  The biggest
change is that instead of being able to "do everything C can do", my focus
was going to be "have a working C compiler". That may sound like a huge
project at first, but I don't think it's as big as you think.  Take for
example the DCPU-16. It is a fictional CPU created by Notch, the creator of
Minecraft, for his upcoming game 0x10c.  Once the specs were released, less
than a month later, multiple DCPU-16 emulators had been written, and LLVM
was ported to output DCPU-16 bytecode.  In less than a month, a fictional
VM became real and had a working C compiler. That makes me believe that a
VM that was created to run both static and dyanmic languages (with a focus
on dynamic) would be possible.

I believe I could have a working core quickly, it was always the runtime
libraries that were going to be the most time consuming, and left to my own
design, wrong the first time.  I would be willing to rearrange my tuits for
the next few weeks to create a working specificaion, bytecode core
and assembler.  I would be willing to do that if there are others willing
to hack on the runtime at the same time as well.  I know that this design
is not based on the current m0 spec, and the interest in my Lorito
prototype faded quickly, but I'm offering something that I think can be
useful in a short period of time.  If there's not much interest in pursuing
this route, that's okay with me.  But my goal would be to get several
languages running on top in short order and being able to interact with
each other shortly after that.

If there's any questions on the design or interest in helping, let me know.
 Otherwise, I'm still hoping that Parrot can get back on track because I do
believe in the mission, even if I don't believe in the code.

-Jon Gentle

On Saturday, February 9, 2013, Allison Randal wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.parrot.org/pipermail/parrot-dev/attachments/20130210/2b8d743b/attachment-0001.html>


More information about the parrot-dev mailing list