At 12:41 PM 9/4/2002 -0400, Andrew Kuchling wrote:
>[Please CC: me on any responses.]
>First reason I don't work on it very much:
>
>1. Frankly, it's not much fun. I can spend my free time writing
>Python code, an environment I like, or I can work in the unfamiliar
>and uncomfortable Parrot build environment and source code, grepping
>through it looking for examples to help me figure out what's going on.
>Guess which option wins most often?
This is no surprise. Parrot documentation will be lacking until
things settle down.
>Some larger reasons:
>
>2. No clear benefit to using Parrot.
>
>What new possibilities does Parrot provide for Python? Stacklessness?
>Better GC? A new I/O layer? Language interop? None of these is more
>than mildly interesting to me, and none is a killer application.
Faster execution times would be on the top of my list.
I'm speaking for Perl, not Python, but last time I checked, neither
language was spectacular in this category.
>Personally, I'm skeptical of the claims of cross-language interop
>because I don't think a library written in Perl will provide an Python
>interface that looks at all idiomatic, and vice versa. You could
I agree with you.
>A big benefit for Python might be if someone writes a Parrot to
>{machine code,.NET} compiler, but there are existing alternatives such
>as Pyrex and no one has written such a Parrot compiler yet, so that's
>not too convincing.
It may not happen either if the JIT is fast enough.
>If every other language was using Parrot, there would be some pressure
>to join them, but given the lukewarm response by other language
>communities, that's not a factor at the moment.
Its too early to have any response, Parrot is still alpha software.
>3. Lack of any real languages on Parrot
>
>I'm slightly worried that Parrot is already succumbing to the lure of
>premature optimization -- counting the number of opcodes executed per
>second, trying to save a C pointer dereference here or there -- before
>the Parrot VM has been shown to be useful as a language target. No
This is just responsible programming. We benchmark to track
progress and we need no excuse to over-optimize..; we ARE
building a virtual CPU you know. :)
>one is running real programs in Perl or Python or Scheme or anything
>on the VM (right?), so any optimizations at this point are just
>guesses, and may not actually be relevant to real programs. This
All opcodes that are used by real programs are relevant. We aren't
dealing with unknown technology here; most of the components
of a VM are proven and supported by academic research and most of
us are pretty smart people so I don't think this is a wasted exercise.
>makes me wonder if the Parrot implementation will just retrace the
>same path as the Perl5 implementation.
I don't call Perl5 a failure. Maybe the implementation is hairy, but it
works well and is THE scripting language of choice for system-admins,
DBAs and countless other professionals.
>I'd rather see a full implementation of a single real language that
>people actually use (Scheme, Python, whatever) on top of an
Eek, Scheme would do little for Parrot's acceptance in the
commercial world, and we all know its the commercial world
that provides most of the fuel to the fire. Seeing a "real" Perl, Python,
Java or C# running on Parrot would be my preference.
>unoptimized Parrot VM, instead of the existing situation of a bunch of
>half-implemented or toy languages on top of an optimized VM. That
>would be a more convincing proof that Parrot can actually handle a
>real language, and gives other languages something to test
>interoperability with.
Its really unfair to size Parrot up in this way. I hope the state of things
hasn't scared you off, we need good people, but it won't stop me
from giving my trickle of support in hopes of creating exactly what
you just mentioned. You, being a Python hacker and open-source
contributor, of all people, should know how slow this game moves.
Thanks for the honest comments,
-Melvin
