Forgot your password?
typodupeerror
Perl Programming

Parrot 1.0.0 Released 120

Posted by timothy
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."
This discussion has been archived. No new comments can be posted.

Parrot 1.0.0 Released

Comments Filter:
  • by Anonymous Coward on Wednesday March 18, 2009 @02:47PM (#27245315)
    One Bytecode to rule them all, One Bytecode to describe them, One Bytecode to bring them all and in the OS bind them.
    • Re: (Score:2, Funny)

      by Yvan256 (722131)

      And that bytecode is.... 42.

      • Re: (Score:2, Informative)

        by Poltras (680608)
        'C'?
        • Re: (Score:3, Informative)

          by IpalindromeI (515070) *

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

          • by Poltras (680608)
            I, uh, never said it was ASCII...
            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.
    • by Anonymous Coward

      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)

        by grcumb (781340)

        SQUAWK! On topic!

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

  • Umm is it me or has the internet been slashdotted?!
    The 2 times I want to read TFA as well, bah!

  • by davidwr (791652) on Wednesday March 18, 2009 @02:54PM (#27245425) Homepage Journal

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

  • What's the performance and stability like?

    I remember doing some benchmarks more than a year ago and plain perl 5 was faster.

    Hope it's much better now...
    • by jandrese (485)
      I would hope that the release version will be more stable than the early beta you must have used over a year ago...
      • Re: (Score:1, Interesting)

        by Anonymous Coward

        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?

    • Slightly off topic: Is there a compiler for Perl, that is not based on bytecode, and therefore is difficult to decompile?
      • Re: (Score:3, Funny)

        by drinkypoo (153816)

        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?

        • by chromatic (9471)

          I thought perl source was considered sufficiently obfuscated that it was safe from reverse-engineering in source form.

          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.

        • by Phroggy (441)

          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

          • by Onymous Coward (97719) on Thursday March 19, 2009 @03:12AM (#27252343) Homepage

            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.

            • by Phroggy (441)

              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.

              And hell yeah, Perl kicks ass. :-)

      • by hardburn (141468) <hardburn@wumpus-cav e . n et> on Wednesday March 18, 2009 @03:38PM (#27246173)

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

      • by jonadab (583620)
        > Is there a compiler for Perl, that is not based on bytecode, and therefore is difficult to decompile?

        I'm pretty sure this is an explicit non-goal for the entire Perl community.
    • by hardburn (141468) <hardburn@wumpus-cav e . n et> on Wednesday March 18, 2009 @03:31PM (#27246003)

      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.

  • So there is a spec for Perl 6? Now there is something novel from Perl camp.
  • by tcsh(1) (683224) on Wednesday March 18, 2009 @03:09PM (#27245669)
    Remember that their plans for the 1.0 release was for a stable API for language implementors, not highly optimized performance.
  • VM question (Score:4, Interesting)

    by benjfowler (239527) on Wednesday March 18, 2009 @03:15PM (#27245755)

    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:VM question (Score:5, Informative)

      by outZider (165286) on Wednesday March 18, 2009 @03:18PM (#27245819) Homepage

      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)

        by VGPowerlord (621254)

        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?

        • by outZider (165286)

          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.

          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].
      • by master_p (608214)

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

        • 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:3, Informative)

      by bernh (1122565)
      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.
      • by Trepidity (597)

        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.

    • Re:VM question (Score:4, Informative)

      by mj41 (1200515) on Wednesday March 18, 2009 @05:17PM (#27247783) Homepage Journal
      chromatic said on reddit.com: [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."

    • Re: (Score:3, Informative)

      by RAMMS+EIN (578166)

      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)

        by Anonymous Coward

        How's TurboVM different from LLVM, which I believe has the same goals?

      • 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?

  • by ptbarnett (159784) on Wednesday March 18, 2009 @03:56PM (#27246493)
    The original Slashdot article from almost 8 years ago: Perl + Python = Parrot [slashdot.org].

    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.

  • Hurry up and get the languages that target it up on http://shootout.alioth.debian.org/ [debian.org]
  • 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.

  • 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

  • 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)
    • by aevans (933829)
      So if practical usability is targeted for 12.0, then we'll have another 6 years to wait, if everything goes well?
  • Dr Sbaitso [wikipedia.org], are you back?

  • 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

  • Quoting post-wash-up lyrics from a long since irrelevant band is symbolic.

This place just isn't big enough for all of us. We've got to find a way off this planet.

Working...