Posted
by
timothy
on Wednesday March 18, 2009 @01:44PM
from the take-a-beak dept.

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."

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.

seems like? What exactly do they have to do it to get you to drop the 'seems like'? I'm pretty sure they can't think of anything else to do to it. Maybe behave like perl(n) where n is current stardate div larrywalls_birthday mod 6?

Perl is very difficult to read if you don't know Perl, by which I mean all of Perl. It's a very complex language with tons of operators and quirky syntax, which means if you encounter something you're not familiar with, you can't look it up in a reference, because you don't even know what you're looking for.

Typically, most people don't learn they entire language; they learn a subset of the language that allows them to do what they need to do. That's fine, and you should be able to read your own programs w

Perl is very difficult to read if you don't know Perl, by which I mean all of Perl.

Rather...

Perl is very difficult to read if you don't know Perl, by which I mean as much of Perl as the guy who wrote the program used.

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.

Perl is very difficult to read if you don't know Perl, by which I mean all of Perl.

Rather...

Perl is very difficult to read if you don't know Perl, by which I mean as much of Perl as the guy who wrote the program used.

Knowing as much of Perl as the guy who wrote the program, in terms of percentage of the language, isn't enough. You have to know the same subset of Perl that the other guy used. If you know 3/4 of the language, and he knows 2/3 of the language, there is no guarantee that your 3/4 will wholly include his 2/3. To be sure that you know his 2/3 of the language, you have to learn the whole language. That was my point.

You don't need to understand all of Perl to understand a given Perl program - you just need to understand the subset of Perl that is being used there.

And honestly, isn't the same true for any language? Myself, for example, I know C but not C++, and if you gave me a complicated C++ program with lots of templates and whatever else C++ has in terms of advanced and arcane features, I'd be at a total loss if I tried to understand it, too.

But that wouldn't mean the program is flawed - or that C++ is flawed. I know languages like PHP have made (some) people expect that they can understand (most of) any new language in a matter of minutes and think that if they can't, the language is flawed, but that simply isn't correct.

Yes, but Perl seems to have a rather more complex syntax than most other languages. For example, JavaScript's syntax is much simpler: there are far fewer operators, strings are immutable so you don't need syntax to modify them inline, arrays are an object class so you use OOP syntax for dealing with them, etc. etc. Because the syntax is less complicated, what's left is usually pretty easy to look up in a reference book (I highly recommend O'Reilly's JavaScript: The Definitive Guide).

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. (I wouldn't maintain code in any language without knowing how to consult the reference material for the language, and I try never to maintain any codebase without a comprehensive automated test suite. Perhaps I'm just picky.)

If you're maintaining Perl code, you should know how to consult perldo

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).

> In my Perl example, you have to recognize that ~ is actually part of> the =~ operator, and that s is part of the s/// operatorOkay, yeah, but that's extremely basic stuff, covered in the very first chapter of every Perl book or tutorial I've ever seen (except, of course, for books that assume you already know the basics, e.g., Effective Perl Programming or Higher Order Perl).

I don't understand the complaint that Perl is "hard to read". I think people are just being lazy and not bothering to learn e

Well, my example was pretty simplistic; of course =~ is something every Perl n00b should be familiar with. There are other syntactic constructs, though, that a lot of beginners just never bother learning (because they can get by without them).

I think people are just being lazy and not bothering to learn even the most basic parts of the language before trying to read stuff written in it,

That pretty much sums it up, I think. Note that PHP is easier for lazy people to read - the syntax is simpler and there are fewer operators, so if you encounter something unfamiliar it's probably a function that you can easily look up on php.net. This does NOT mean

If epigraphs consisted of dull words to be interpreted literally, nobody would bother.

Tolkein wrote some turgid prose himself.

Of course, I named my latest Parrot release after an Ed Wood movie, so we've always hewed toward the postmodern "refer to something" approach rather than trying to appease the literary critics of the world. It's a release announcement. If you want to correct bad poetry in the world, start with some of the social networking sites.

Surprisingly. The idea is to do a full language specification, so there can be many implementations of a language, similar to how Java (theoretically) works. This is also why there is an absolutely huge, yet incomplete, test suite. More tests are passing weekly, but more tests are being generated weekly.

I'm not very good with thedetailed explanation, as I am not a Parrot developer, but Parrot's VM is geared toward dynamically typed languages like Perl, Python, Ruby, and PHP. The JVM and CLR are geared toward static typed languages, which is why dynamic language ports to the CLR generally require code changes and cleanup to work properly under those environments.

Parrot gives all the benefits of a virtual machine to the dynamic side of the language aisle, while being incredibly easy to extend and build on, and is open source from the start.

I'm not very good with thedetailed explanation, as I am not a Parrot developer, but Parrot's VM is geared toward dynamically typed languages like Perl, Python, Ruby, and PHP. The JVM and CLR are geared toward static typed languages, which is why dynamic language ports to the CLR generally require code changes and cleanup to work properly under those environments.

[Citation needed]

So, any Jython/IronPython or JRuby/IronRuby people around to share their insights?

Big citation needed. I don't know enough about them for it to be completely accurate on code modification, and it's likely a lot has changed since I last looked, so I'm prepared to admit I'm totally wrong. All I do know is that Parrot is tailored to dynamic languages.

I fall into neither of those python/ruby groups you mention... My understanding is that they've had to perform some magic behind the scenes with class loaders and reflection etc to obtain reasonable performance. Sun's hotspot vm doesn't support tail-recursion, so lisp dialect clojure has had to add language keywords to simulate it.

The real difference is:the JVM and the CLR use a stack based idealized machine. That means the byte code has operations like: load constant 2 on stack and load constant 11 and multiply where the last opcode pops the 2 numbers from the stack, multiplies them and places the result back on the stack.

Note that.NET and JVM have been built with a focus on static languages like C# and Java.
As far as I know Parrot is a register based virtual machine and should be especially suited for _dynamic_ languages like Perl, Python, Ruby,...
Time will tell if the theoretic advantages here will result in a better real-world performance as the other VMs.

One interesting feature of the competition is that.NET and JVM are also looking to make themselves more friendly to dynamic languages, so it's not a totally stationary target. The most promising seems to be the proposal to add an "invokedynamic" bytecode [jcp.org] to the JVM, which would allow [headius.com] a bunch of stuff dynamic languages do to be handled by the JVM (instead of them having to build their own dispatch mechanisms on top of it).

I don't know about better, but Parrot is different from the jvm and clr, in that it is register-based, rather than stack-based. And of course Parrot is Open Source. The clr is not and jvm was not at the time parrot was started.

Parrot is at a higher level than LLVM. Parrot deals with things like multiple dispatch, garbage collection, closures, and more at the virtual machine level. LLVM is meant to be an efficient way to target a real machine in the back end of a compiler that supports optimization and JIT.

Parrot could actually target LLVM as a backend. There have actually been tests showing that Parrot compiles under llvm-gcc. Something has to be the front end for any compiler or virtual machine, and Parrot is that. The back end

"It's not so much that the CLR's limitations prevent it from running dynamic languages but that the CLR's limitations require you to invent a lot of your own infrastructure to run dynamic languages. If the CLR in itself assumes that it can resolve all method dispatches (or jump targets or attribute accesses) statically at compile time, you have to invent your own dynamicity atop that. If the CLR does not support first class functions, you have to invent your own approach. If the CLR does not support first-class continuations, you have to invent your own calling structure. Ditto named parameters, optional parameters, default parameters, and whatever other features that the CLR doesn't support.

I'm not saying that the CLR doesn't support all of those features -- I know that it does support some of them, to some degree. The DLR supports more. The question is whether Turing equivalence (and I hate this argument) is sufficient, or whether you're better off not inventing your own method dispatch system."

Personally, I believe they are all doing it wrong, and all in the same way. They all assume things about the programming languages that will target the VM, and build the VM to support the constructs they've assumed the language will use.

I am much more in favor of a language-agostic approach. In my own TurboVM [sourceforge.net], I have instead chosen to implement a simple, RISC-like instruction set, reasoning that this would allow the same techniques that are used to implement existing languages on real hardware to be used to

I am much more in favor of a language-agostic approach. In my own TurboVM, I have instead chosen to implement a simple, RISC-like instruction set, reasoning that this would allow the same techniques that are used to implement existing languages on real hardware to be used to implement languages on TurboVM. No need to work around the fact that you get objects and methods, garbage collection, dynamic typing, etc. when you don't want them - TurboVM gives what a real machine would give you, without any bias towards specific programming languages.

The point of having those multi-language VMs is to get different languages to interoperate more or less seamlessly - call methods on a Python class from Ruby, etc. How does your approach solve that problem?

Tectonic shifts in computing begin with humble first steps like this. I know it was years worth of work, and you had to suffer lots of naysayers along the way. So, great job, and I hope to see less humble moves as we go forward.

The next goals are outlined here [parrot.org].
Basically, they target one major release every six months, bumping each time the version number by 0.5. The next focus are:
1.5: integration, interoperation, and embedding
2.0: production users
2.5: portability
3.0: independence from other languages (everything is parrot on parrot)

The concept must be completely out of my reach. I look at Parrot and think, "OK I can write to the registers. This speeds up code for me on C. But, on C I'm writing to real registers. Parrot is a VM which means I'm writing to virtual registers which then gets translated to machine code." Wouldn't everything get lost in the translation depending on how well the VM is written for the specific arch of the machine Parrot is running on? Also, will the people running the code I'm writing need to have Parrot

Ha - this may be the answer to a recent 'Ask Slashdot' article on Cross-Language Code Reuse:

Hope For Multi-Language Programming?http://ask.slashdot.org/article.pl?sid=09/02/28/037256 [slashdot.org] From a comment there:There is one possible bright spot I know of in the multi-language world: the development of things like the Parrot virtual machine, which is intended to be an efficient backend for all dynamic languages, including (but not limited to) Perl 6. It seems unlikely to me that this technical achievement is going t

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".

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

I find that somewhat typical of beautiful theories. Everything is wonderful with stack based interpreters until someone points out that it borks the branch predictor. Good luck cooking up a telepathic branch predictor. (And you thought your original problem was hard?)

As for the JIT comment, most of the Java code I use on a daily basis (Eclipse, JIRA) suffers from extreme lurch.

Why does it take two minutes to close and reload the same Eclipse workspace? I think the network mandated virus scanner is so bu

As for the JIT comment, most of the Java code I use on a daily basis (Eclipse, JIRA) suffers from extreme lurch.

Swapping. The Windows VMM is extremely aggressive, swapping out any memory that hasn't been accessed recently, even if that memory isn't needed by another program. Unfortunately, this plays out badly when the garbage collector comes along and tries to scan the heap. The result is a lot of thrashing.

Linux doesn't have nearly the same difficulties with Java "lurching" as Windows does, because the Li

Why does it take two minutes to close and reload the same Eclipse workspace? That is an Eclipse problem, not a Java problem. Eclipse is doing insane amounts of work during start up time, and has an absurd amount of meta data stored in the workspace. The whole idea that an IDE even needs a workspace is so strange...Try using an IDE like CodeGuide, www.omnicore.com. Or if you like it: IDEAs IntellyJ IDE or NetBeans from Sun. I don't really like NetBeans... but lots of people I know, do like it. Also worth

That's because register-based interpreters are faster than stack-based interpreters. Generally speaking, the fewer instructions you run in a bytecode interpreter, the faster it will execute. That is the argument made in the paper posted by mj41 above.

When you throw a JIT into the mix, things change rapidly. You stop being concerned about the interpreter speed and begin worrying more about machine code optimizations. What's good for the goose may be good for the gander, but what's good for the interpreter is

What's good for the goose may be good for the gander, but what's good for the interpreter is not always good for the JIT.

That doesn't mean a register machine is any worse than a stack machine for JITting. In particular, some of the Dis papers from the Plan 9 research suggest that avoiding unnecessary memory access can improve execution speed as well. The approach they suggest there is clever register allocation with a register-based machine. For example, if you inline function calls, the JIT can reallo