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."
Lord of the Bytecodes (Score:3, Funny)
Re: (Score:2, Funny)
And that bytecode is.... 42.
Re: (Score:2, Informative)
Re: (Score:3, Informative)
ASCII character 42 (decimal) is '*'. ASCII character 0x42 (hex) is 'B'. Sorry, try again.
Re: (Score:2)
And I asked a question... which you answered succesfully! Good job! Here's a hundred point to you and your team! See you all at home, after these messages.
Parrot 1.0.0 Released (Score:2, Funny)
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.
SQUAWK! On topic!
Re: (Score:3, Funny)
For god's sake, someone nail his feet to the pedestal.
Down too?! (Score:1)
Umm is it me or has the internet been slashdotted?!
The 2 times I want to read TFA as well, bah!
Re:Down too?! (Score:4, Informative)
This is the first time I heard about Parrot, and it really got my attention as well.
I know it's common knowlegde, but you can get more information in wikipedia:
http://en.wikipedia.org/wiki/Parrot_virtual_machine [wikipedia.org]
Enjoy!
Re:Down too?! (Score:4, Informative)
try this:
http://lwn.net/Articles/324196/ [lwn.net]
Re: (Score:3, Funny)
Probably; that usually happens when someone posts a link to the internet on Slashdot. Someone really needs to update the server for the internet.
Re: (Score:1)
It's pining for the fjords.
Slashdotted parrot (Score:4, Funny)
I'll tell you what's wrong with it, my lad. 'E's slashdotted, that's what's wrong with it!
Re:Slashdotted parrot (Score:5, Funny)
Not it's not! It's just swapping!
Re: (Score:2)
That server wouldn't 'voom' 'cause you put four million requests through it! 'E's bleedin' slashdotted!
Re: (Score:1)
Re:Slashdotted parrot (Score:4, Funny)
:) I wish I had another mod point for you. (Score:2)
n/t
Is it really ready? (Score:2)
I remember doing some benchmarks more than a year ago and plain perl 5 was faster.
Hope it's much better now...
Re: (Score:2)
Re: (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?
Compiler for Perl? (Score:2)
Re: (Score:3, Funny)
Slightly off topic: Is there a compiler for Perl, that is not based on bytecode, and therefore is difficult to decompile?
I thought perl source was considered sufficiently obfuscated that it was safe from reverse-engineering in source form. Why on Earth would you want to do something like this anyway?
Re: (Score:1)
If you don't know Perl, you may have difficulty reading programs written in Perl. (I have a similar problem with Mandarin.) If you do know Perl, try B::Deparse [cpan.org] for decoding obfuscated Perl.
Re: (Score:1)
Even so, over a billion people seem to get by speaking some dialect of Chinese; clearly my ignorance of the language is no barrier to their communication!
Re: (Score:1)
That sounds like every encounter I've ever had with Emacs Lisp.
Re: (Score:2)
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?
Re: (Score:2)
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
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: (Score:2)
Rather...
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.
And hell yeah, Perl kicks ass. :-)
Re: (Score:2)
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).
Consider this line in
Re: (Score:1)
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
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).
Re: (Score:1)
> the =~ operator, and that s is part of the s/// operator
Okay, 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
Re: (Score:2)
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
Re:Compiler for Perl? (Score:5, Insightful)
Perl 5 isn't really bytecode at all. It basically just walks the parse tree directly.
Perl 6/Parrot is bytecode just as those from Python or Java have come to expect. Perl 5 could be reimplemented this way, but nobody seems to want to bother.
If your goal is to obfuscate your code to prevent people from copying it, please give up [perlmonks.org].
Re: (Score:2)
Perl 5 isn't really bytecode at all. It basically just walks the parse tree directly.
Yeah, no, that's not actually true.
http://www.xav.com/perl/lib/B/Bytecode.html [xav.com]
Re: (Score:3, Informative)
http://search.cpan.org/~nwclark/perl-5.8.9/ext/B/B/Bytecode.pm [cpan.org]:
NOTICE
There are also undocumented bugs and options.
THIS CODE IS HIGHLY EXPERIMENTAL. USE AT YOUR OWN RISK.
AUTHORS
Originally written by Malcolm Beattie and modified by Benjamin Stuhl .
Rewritten by Enache Adrian , 2003 a.d.
B::Bytecode is an experimental feature that's been largly abandoned since 2003. Perl5 is too much of a mess to make a bytecode compiler work. That's why Parrot exists.
Re: (Score:1)
I'm pretty sure this is an explicit non-goal for the entire Perl community.
Re:Is it really ready? (Score:5, Informative)
Version 1 is supposed to be reasonably complete and provide a consistent API for language developers.
Version 2 is intended to be the production-ready version. According to the roadmap laid out last Dec., that's due to come in another year. So far, they've stuck to the roadmap pretty well.
Re: (Score:2, Insightful)
Tolkein didn't write a line of Perl 5 either, yet Larry quotes him in his release announcements. Epigraphs are long-established literary traditions.
Re: (Score:1)
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.
Re: (Score:1)
Re: (Score:3, Funny)
When we all know the real announcement ought to have been "Brawk! Ready to sail"
Re: (Score:1, Informative)
She's one courageous lady and I think the song is a decent tribute.
Each to his own though.
Perl 6 reference implementation (Score:1)
Re:Perl 6 reference implementation (Score:4, Insightful)
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.
1.0 is for a stable API (Score:4, Informative)
Comment removed (Score:4, Interesting)
Re:VM question (Score:5, Informative)
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.
Re: (Score:3, Insightful)
[Citation needed]
So, any Jython/IronPython or JRuby/IronRuby people around to share their insights?
Re: (Score:2)
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.
Re: (Score:2)
Sun have made some progress in this area by hiring some of the jruby developers, introducing new bytecodes [jcp.org] and prototyping a new language independent vm [java.net].
Re: (Score:2)
So, the only real difference between JVM and Parrot is dynamic dispatch? it certainly sounds like work duplication to me.
The JVM bytecode spec defines a Turing-complete machine. Why isn't dynamic dispatch implemented in it?
Everyone nowadays has a VM...
Re: (Score:2)
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.
Parrot uses a idealized register machine. That means byte codes look like: load constant 2 into register R1 and load constant 11 into register R8 and multiply R1 with R8 storing the result in R0.
I don't know if Par
Re: (Score:2, Informative)
Also, .NET 4.0 is supposed to ship with the Dynamic Language Runtime (DLR): http://en.wikipedia.org/wiki/Dynamic_Language_Runtime [wikipedia.org]
Re: (Score:2)
DLR is already available separately for existing .NET versions. That's how IronPython works today.
Re: (Score:3, Informative)
Re: (Score:2)
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).
Re: (Score:2)
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.
Mono (Score:2)
And of course Parrot is Open Source. The clr is not and jvm was not at the time parrot was started.
This CLR is free software [mono-project.com], but then it wasn't released until 2004.
Re: (Score:3, Informative)
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
Re:VM question (Score:4, Informative)
"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."
Re: (Score:3, Informative)
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
Re: (Score:1, Insightful)
How's TurboVM different from LLVM, which I believe has the same goals?
Re: (Score:2)
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?
The original Parrot was an April Fool's joke (Score:5, Informative)
It included a mock press release: Perl and Python Announce Joint Development [perl.org].
And a joint "interview" of Larry and Guido [perl.com].
O'Reilly Media even tossed in a bogus book announcement: Programming Parrot in a Nutshell [oreilly.com].
A few days later, O'Reilly published The Story Behind the Parrot Prank [oreilly.com].
The name was eventually adopted by this project.
Re: (Score:1)
Re: (Score:1)
Re: (Score:2)
Thanks for the reminder! That was an enjoyable few days.
Re: (Score:2)
The language is far from dead.
Re: (Score:2)
The same douchebags that think PHP is enterprise.
Benchmarks (Score:2)
Re: (Score:1)
Perl 6 before end of century? (Score:2)
So, we might actually see something called Perl 6 released before the end of the century? They've only been talking about it for ever, it seems.
Re: (Score:2, Informative)
Congrats Parrot Team! (Score:1)
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.
Cheers,
Dave
Parrot development goals for each major release (Score:2)
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)
Re: (Score:1)
Dr Sbaitso ? (Score:2)
Dr Sbaitso [wikipedia.org], are you back?
I just don't get it (Score:2)
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
Cross-Language Code Reuse (Score:2)
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
Perl was cool when U2 was cool (Score:1)
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: (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
Re: (Score:3, Informative)
Re: (Score:1, Insightful)
The paper is a case for interpreted register virtual machines, but it only makes a passing reference to virtual machines with just-in-time compilers.
Re: (Score:2)
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
Re: (Score:1, Insightful)
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
Re: (Score:2)
Why does it take two minutes to close and reload the same Eclipse workspace? ... ... but lots of people I know, do like it. Also worth
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
Re: (Score:2)
Interestingly, Opera's new ECMAscript engine has a register-based byte-code instruction set.
http://my.opera.com/core/blog/2009/02/04/carakan [opera.com]
Re: (Score:3, Informative)
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
Re: (Score:1)
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
Re: (Score:2)
Hopefully next up: Google moon base