Comparing Python and Parrot

mAriuZ writes "In many ways, it seems like Python and Parrot are from different planets. In Python, the general approach seems to be to reduce everything possible to a canonical form as early as possible, and then deal with everything consistently. In Parrot, the general approach seems to be to leave everything in its original form as long as possible, and then deal with everything separately."

Comments

Python:

[brilinux]

This Parrot is no more!

Soon enough...

[namekuseijin]

Python will be running on Parrot. So everything will be ok. ( i hope )

There's no comments

[Anonymous Coward]

mmm, Netcraft confirms that Parrot is dying..

Re:There's no comments

[Anonymous Coward]

Actually, Netcraft confirms that it's just resting.

Re:There's no comments

[Anonymous Coward]

No, Netcraft confirms that Polly is an ex-parrot. It is no more.

Some clarification

[Scarblac]

Note: TFA compares the virtual machine of Python with Parrot; Parrot is a virtual machine designed for running bytecode of several languages, including Python and Perl (as far as I know - perhaps Parrot is more than that, now).

This isn't about differences of the language Python with another language, but about how the same language runs with completely different bytecode on the two systems.

More info on Parrot

[Chilltowner]

More about Parrot here.

It's pretty interesting stuff. As I understand it, they're making a virtual machine that is better suited to running code from weakly-typed languages than, say, the JVM would be. I'd really like to see what comes out of the Python-Parrot combo, with or without the pies thrown.

Re:More info on Parrot

[fredrikj]

they're making a virtual machine that is better suited to running code from weakly-typed languages...

Wrong! They're making a virtual machine that is better suited to dynamically typed languages.

(Python is strongly typed.)

Re:More info on Parrot

[hsoft]

Strongly typed? Are we talking about the same Python or should I revise my definition of "strongly typed"? This thing is typeless!

For example, if I want to create a function that only accepts a certain type of instance to be passed as a parameter I must do something like that (if I don't need to, I would love to know what easier way there is to do that)

def MyFunc(aMyInstance):
if not isinstance(aMyInstance,TheClassIWant): raise TypeError
DoStuff()

MyFunc(SomeInstanceOfAClassIDontWant) #exception at runtime

However, if I comment out the typecheck line, aMyInstance could be *any* type, and an exception would be raised only if, in MyFunc, I call for an attribute aMyInstance doesn't have.

Maybe that my definition of "strongly typed" is completely wrong, but I think that Python is typeless, as opposed to Object pascal, which is strongly typed:

procedure MyFunc(aMyInstance:TheClassIWant);
begin
DoStuff;
end;

MyFunc(SomeInstanceOfAClassIDontWant); //compile error

In my head, "strongly typed" != "object oriented".

Note: I only started Python a week ago, and I love it, especially wxPython.

Re:More info on Parrot

[pkhuong]

I don't know Python, but it very well be so-called duck typing. And it is still strongly typed, since it won't allow you to DoStuff on stuff that don't fit its operations.

Python, you whore

[quamaretto]

Python is all over the place these days. It has its own bytecode format, and yet it was being used in .net in that light languages thingum a few days ago, now today we see it running on parrot... What next, a Smalltalk VM implementation?

:O

*runs off*

Mark Sparshatt is working on a Parrot frontend...

[tcopeland]

...for Ruby here.

Still lots to do but it's a start...

My Thoughts

[RAMMS EIN]

Basically, TFA seems to highlight a few issues one has to deal with when porting Python to Parrot. These are both differences between the Python VM and the Parrot VM (these affect Python/Parrot vs. CPython) and differences between what Perl and Python (these affect Python/Parrot vs. Perl/Parrot).

The first category of differences is analogous to differences between various real machines. As long as a virtual machine provides a flexible enough instruction set, any language can be made to run well on it. If not, the VM is badly designed, even if you want to run just one language on it (because you cannot arbitrarily improve your language without having to improve the VM).

The second class of differences is more tricky. Ideally, languages that target Parrot would be able to use each other's objects. However, this requires consistent treatment of objects and methods across all languages that target the VM.

I believe that both of these challenges can be overcome. The key to keeping VMs flexible is to avoid making assumptions about the language they will be required to execute. As long as the VM does not impose any structure, its primitives can be arbitrarily combined, allowing any language to run efficiently.

The key to allowing languages to work with one another's objects is to provide a standard set of primitive types and to establish conventions on how to combine these types (e.g. each composed value contains a reference to a description of the contents of the type). I think a convention is better than a mechanism or requirement here, as the latter options would take too much flexibility out of the system.

Neee!

[macdaddy357]

I got an email about Python and Parrot, but I think it was just spam.

Ruby

[alien at large]

Ruby talking about Python and Parrot.
I'm confused already...