Comparing Python and Parrot 15
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."
Python: (Score:3, Funny)
Soon enough... (Score:1)
Re:There's no comments (Score:4, Funny)
Some clarification (Score:5, Informative)
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 (Score:3, Informative)
More about Parrot here [parrotcode.org].
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 [www.hole.fi].
Re:More info on Parrot (Score:3, Informative)
Wrong! They're making a virtual machine that is better suited to dynamically typed languages.
(Python is strongly typed.)
Re:More info on Parrot (Score:1)
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 a
Re:More info on Parrot (Score:2)
Python, you whore (Score:1)
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?
*runs off*
Mark Sparshatt is working on a Parrot frontend... (Score:4, Informative)
Still lots to do [rubyforge.org] but it's a start...
My Thoughts (Score:4, Informative)
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! (Score:1)
Ruby (Score:1)
I'm confused already...