[Please CC: me on any responses.]
I follow the perl6-internals list through checking the archive, and
noticed Jerome's posting. I wrote the parrot-gen.py script that he
pointed to. Here are my comments on this issue.
(Note that I do not speak for the python-dev gang as a whole, but
AFAIK I'm the only current or former python-dev'er who's looked at
Parrot in any detail.)
First, the mailing list name is a complete non-issue; I don't care.
Having it be @perl.org doesn't matter, either.
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?
I initially wrote parrot-gen.py because I wanted to play a bit with
Parrot and see what it took to generate Parrot bytecode from Python.
Parsing Python code is trivial with the Compiler/ package in 2.2, so
it was just a matter of code generation. Every so often, I'll update
my copy of the Parrot CVS tree and try to update the script to match
it. I also have incomplete PythonString.pmc and PythonFloat.pmc files
lying around someplace, and got halfway through updating the code to
use imcc instead of assemble.pl, but the task isn't enough fun to make
me bother finishing those off.
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.
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
write a Python wrapper to make a Perl library look more natural, but
now 1) we're all writing wrapper code that will introduce more bugs,
2) as a user chasing a problem, I now have to debug the interface
between the library and the wrapper code, 3) as a user, now I'll have
to read Perl/Ruby/Scheme/whatever code in the underlying library. The
way things are now, at least I only need to know 2 languages, Python
and C.
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.
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.
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
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
makes me wonder if the Parrot implementation will just retrace the
same path as the Perl5 implementation.
I'd rather see a full implementation of a single real language that
people actually use (Scheme, Python, whatever) on top of an
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.
--amk (www.amk.ca)
Then the shadows began to gather; first little furtive ones under the table,
and then bolder ones in the dark panelled corners.
-- H.P. Lovecraft, "The Strange High House in the Mist"
