Slashdot Mirror


Parrot 1.0.0 Released

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

34 of 120 comments (clear)

  1. Lord of the Bytecodes by Anonymous Coward · · Score: 3, Funny

    One Bytecode to rule them all, One Bytecode to describe them, One Bytecode to bring them all and in the OS bind them.

    1. Re:Lord of the Bytecodes by IpalindromeI · · Score: 2, Informative

      ASCII character 42 (decimal) is '*'. ASCII character 0x42 (hex) is 'B'. Sorry, try again.

      --

      --
      Promoting critical thinking since 1994.
  2. Slashdotted parrot by davidwr · · Score: 4, Funny

    I'll tell you what's wrong with it, my lad. 'E's slashdotted, that's what's wrong with it!

    --
    Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
    1. Re:Slashdotted parrot by Yvan256 · · Score: 4, Funny

      Not it's not! It's just swapping!

    2. Re:Slashdotted parrot by QRDeNameland · · Score: 3, Funny

      It's pining for the DWORDs!

      --
      Momentarily, the need for the construction of new light will no longer exist.
  3. Re:Down too?! by Volanin · · Score: 3, 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

    Enjoy!

    --
    If I clone myself, can I call it a thread?
    If a girl winks to us, can I call it a race condition?
  4. Re:Down too?! by DragonWriter · · Score: 2, Funny

    Umm is it me or has the internet been slashdotted?!

    Probably; that usually happens when someone posts a link to the internet on Slashdot. Someone really needs to update the server for the internet.

  5. 1.0 is for a stable API by tcsh(1) · · Score: 4, Informative

    Remember that their plans for the 1.0 release was for a stable API for language implementors, not highly optimized performance.

  6. Re:Perl 6 reference implementation by outZider · · Score: 3, 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.

    --
    - oZ
    // i am here.
  7. VM question by benjfowler · · Score: 3, 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...

    1. Re:VM question by outZider · · 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.

      --
      - oZ
      // i am here.
    2. Re:VM question by bernh · · Score: 3, Informative

      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.

    3. Re:VM question by VGPowerlord · · Score: 2, Insightful

      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?

      --
      GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
    4. Re:VM question by mr_mischief · · Score: 2, 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 will need to be tweaked for different targets anyway, and LLVM may well be one of those.

    5. Re:VM question by ninkendo84 · · 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

      --

      $ make love
      make: don't know how to make love. Stop
    6. Re:VM question by mj41 · · Score: 4, Informative
      chromatic said on reddit.com:

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

    7. Re:VM question by RAMMS+EIN · · Score: 2, 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, 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.

      --
      Please correct me if I got my facts wrong.
  8. Re:From the Release Announcement by chromatic · · Score: 2, Insightful

    What other reason is there for this inane drivel being reproduced in the release announcement?

    Tolkein didn't write a line of Perl 5 either, yet Larry quotes him in his release announcements. Epigraphs are long-established literary traditions.

  9. Parrot 1.0.0 Released by Anonymous Coward · · 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!

    1. Re:Parrot 1.0.0 Released by grcumb · · Score: 2, Funny

      SQUAWK! On topic!

      For god's sake, someone nail his feet to the pedestal.

      --
      Crumb's Corollary: Never bring a knife to a bun fight.
  10. Re:Is it really ready? by hardburn · · Score: 4, 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.

    --
    Not a typewriter
  11. Re:Compiler for Perl? by drinkypoo · · 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?

    --
    "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
  12. Re:From the Release Announcement by dkleinsc · · Score: 2, Funny

    When we all know the real announcement ought to have been "Brawk! Ready to sail"

    --
    I am officially gone from /. Long live http://www.soylentnews.com/
  13. Re:Compiler for Perl? by hardburn · · Score: 4, 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.

    --
    Not a typewriter
  14. The original Parrot was an April Fool's joke by ptbarnett · · Score: 5, Informative
    The original Slashdot article from almost 8 years ago: Perl + Python = Parrot.

    It included a mock press release: Perl and Python Announce Joint Development.

    And a joint "interview" of Larry and Guido.

    O'Reilly Media even tossed in a bogus book announcement: Programming Parrot in a Nutshell.

    A few days later, O'Reilly published The Story Behind the Parrot Prank.

    The name was eventually adopted by this project.

  15. Re:I can't believe it! by mr_mischief · · Score: 3, 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".

  16. Re:I can't believe it! by Anonymous Coward · · 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.

  17. Re:Perl 6 before end of century? by mj41 · · Score: 2, Informative

    There is Perl 6 release each month.

  18. Re:I can't believe it! by mj41 · · Score: 3, Informative

    The Case for Virtual Register Machines, Brian Davis, Andrew Beatty, Kevin Casey, David Gregg and John Waldron, 12.6.2003, PDF

  19. Re:Compiler for Perl? by hardburn · · Score: 2, Informative

    http://search.cpan.org/~nwclark/perl-5.8.9/ext/B/B/Bytecode.pm:

    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.

    --
    Not a typewriter
  20. Re:Compiler for Perl? by Onymous+Coward · · Score: 3, Interesting

    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.

  21. Re:I can't believe it! by AKAImBatman · · Score: 2, 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 not always good for the JIT.

    Interestingly, there is only one Javascript JIT in wide distribution at the moment. That is Chrome's V8. Tamarin is also used in Flash 9 & 10 and is expected in future versions of Firefox.

    Unfortunately, JITs are much more resource intensive to develop and maintain than interpreters. Thus a small company like Opera isn't going to make a JIT their first priority. A fast interpreter makes a lot more sense from their perspective. Especially when the Javascript engine spends the vast majority of its time in native APIs.

  22. Re:Compiler for Perl? by Phroggy · · Score: 3, 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 the String.replace method, 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).

    --
    $x='S24;r)>63/* h@<5+oZ)32"5cz';$me='phroggy'x$];
    $x=~y+ -xz+\0-Tx+;print$_^chop$me for split'',$x;