Parrot 1.0.0 Released 120
outZider writes "Parrot 1.0.0 was released last night! The release of Parrot 1.0 provides the first "stable" release to developers, with a supportable, stable API for language developers to build from. For those who don't know, Parrot is a virtual machine for dynamic languages like Perl, PHP, Python, and Ruby, and is best known as the virtual machine for Rakudo, the reference implementation of Perl 6."
VM question (Score:4, Interesting)
Question from somebody who's done some compiler work with VMs but not Parrot...
What does Parrot do that other VMs can't (e.g. the .NET dynamic language runtime on the CLR, or the JVM?)
Without knowing better, it seems like a lot of duplicated effort to me...
Re:Is it really ready? (Score:1, Interesting)
I would hope that the release version will be more stable than the early beta you must have used over a year ago...
'Early'? Because nothing good came out of the first six years of development?
Re:I can't believe it! (Score:4, Interesting)
Considering the JVM is a stack machine VM for statically typed languages, .NET is a stack machine VM for statically-typed languages, and Parrot is a register machine VM built for dynamically-typed languages perhaps it's not so "me too".
Re:I can't believe it! (Score:2, Interesting)
The differences aren't nearly as profound as you might think. Keep in mind that when the software is translated from bytecode to native code via JIT is when the real magic happens.
Since the Java and .NET implementations are further abstracted from the underlying hardware implementation, their VMs have a lot of opportunity to optimize between the registers and the stack. They can even undo certain optimizations and realign their mappings between stack and registers. (The ability to reoptimize is why the JVM is referred to as "Hotspot". It looks carefully for "hot spots" in the code where much of the execution time is being spent, then optimizes the code according to how it has been used at runtime.)
The Parrot VM's use of registers makes it easier to map those registers to the underlying hardware, but it makes it more difficult for the JIT to decide what belongs in a register and what should be moved to stack. The bytecode may force the use of registers that end up not being ideal at runtime. Similarly, the VM may miss the opportunity to move critical stack information to registers, thereby slowing down the execution of the code. The obvious solution is to abstract away from the registers and treat them as part of the stack. From there, the JIT can treat these values holistically. And thus we end up with a solution that looks a lot like a stack-based VM.
Mod grandparent up. Mod parent down.
Re:Compiler for Perl? (Score:4, Interesting)
Rather...
But, yeah, I'm with you. The basic idea is that you can't read Perl if you're not literate. At least to the degree of the author of the work you're reading. So, basically, anyone who says Perl is hard to read is a bystander.
Perl can be hard to read if you don't know it. But it can be wonderfully concise if you do. That concision is valuable, so I'll take that. Even if it means having to learn the language first.
Re:Compiler for Perl? (Score:4, Interesting)
If you don't know the language, what are you doing maintaining Perl code? I consider that professionally irresponsible, at least if you're getting paid.
Oh, absolutely, no question there. I was thinking of people messing around for fun, not getting paid to maintain Perl code in a professional environment.
(Where do you look up the /g flag for the JavaScript example?)
When you look up [google.com] the String.replace method [w3schools.com], it should explain /g there. In my Perl example, you have to recognize that ~ is actually part of the =~ operator, and that s is part of the s/// operator; once you know what these are, you can look them up in perlop (and indeed, /g is explained there).
Obviously this isn't a realistic example; any Perl beginner should know the syntax I used. My point was that because other languages rely more heavily on functions to accomplish things that Perl has a unique syntax for (which makes Perl easier and more fun to write), other languages are easier to read because when you come to a function you're not familiar with you can easily look it up. With Perl, if you don't recognize the syntax, you don't know what to look up, so you're stuck (or you misinterpret what's going on).