Slashdot Mirror

← Back to Stories (view on slashdot.org)

Parrot 1.0.0 Released

Posted by timothy on 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."

120 comments

  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 Yvan256 · · Score: 1, Funny

      And that bytecode is.... 42.

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

      'C'?

      --
      Of Code And Men
    3. 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.
    4. Re:Lord of the Bytecodes by Poltras · · Score: 1

      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.

      --
      Of Code And Men
  2. Down too?! by x78 · · Score: 1

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

    --
    Don't panic
    1. 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?
    2. Re:Down too?! by Randle_Revar · · Score: 3, Informative

      try this:
      http://lwn.net/Articles/324196/

      --
      Climate Progress - Hell and High Water
    3. 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.

    4. Re:Down too?! by jo42 · · Score: 1

      It's pining for the fjords.

  3. Um, "yay!"? by Anonymous Coward · · Score: 0

    Sorry, exclamation points in summaries always throw me off.

  4. 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 Millennium · · Score: 1

      That server wouldn't 'voom' 'cause you put four million requests through it! 'E's bleedin' slashdotted!

    3. Re:Slashdotted parrot by Camann · · Score: 1

      Remarkable VM, the Parrot, idn'it, ay? Beautiful interface!

      --
      I can't believe you don't know what a Hasemalphaginnojinglanaporphomism is.
    4. 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.
    5. Re:Slashdotted parrot by Anonymous Coward · · Score: 0

      The interface doesn't come into it - e's deadlocked!

  5. Is it really ready? by TheLink · · Score: 1

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

    --
    1. Re:Is it really ready? by jandrese · · Score: 1

      I would hope that the release version will be more stable than the early beta you must have used over a year ago...

      --

      I read the internet for the articles.
    2. Re:Is it really ready? by Anonymous Coward · · 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?

    3. 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
    4. Re:Is it really ready? by Anonymous Coward · · Score: 0

      4-5 years worth of alphas from what I remember.

  6. From the Release Announcement by Anonymous Coward · · Score: 0, Insightful

    You're packing a suitcase for a place none of us has been
            A place that has to be believed to be seen
            You could have flown away
            A singing bird in an open cage
            Who will only fly, only fly for freedom...

            What you've got they can't deny it
            Can't sell it, can't buy it
            Walk on...

            -- U2, "Walk On"

    Did Bono take time of from being a pompous narcisist to contribute to the project? What other reason is there for this inane drivel being reproduced in the release announcement?

    At least it's text only and we were spared a blast of bland, derivative corporate rock. I stopped reading after "U2", "Walk On" -- "Fuck Off" more like!

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

      --
      how to invest, a novice's guide
    2. 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/
    3. Re:From the Release Announcement by Anonymous Coward · · Score: 0

      The less you know, the more you believe.
      -- Bono (on a momentary visit to reality)

      Bono isn't Tolkein, he's a smarmy, insincere and egotistical corporate rock "artist". Reproducing his terrible poetry serves no purpose, neither presenting context nor inviting comparison. If epigraphs consisted of dull words to be interpreted literally, nobody would bother.

      Or is the context that the parrot project (like Bono) is courting idolatry by being presented as some kind of saviour? Thats the most charitable literary comparison I can come up with.

    4. Re:From the Release Announcement by chromatic · · Score: 1

      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.

      --
      how to invest, a novice's guide
    5. Re:From the Release Announcement by Henry+Bone · · Score: 1, Informative
      I like those lyrics. The song's about Aung San Suu Kyi.

      She's one courageous lady and I think the song is a decent tribute.

      Each to his own though.

    6. Re:From the Release Announcement by aevans · · Score: 1

      Don't get me wrong, I love perl, and I love your work. But I don't like U2 anymore and I've given up on Parrot. There've been bigger fools and more vocal than me, but few of them as aware of it.

  7. I can't believe it! by Anonymous Coward · · Score: -1, Troll

    1.0 is finally released! Whoo hoo! Through all that hard work and determination, they made it just in time for everyone to continue ignoring it.

    --
    Java: New, hip, and cool
    .NET: Copycat, Microsoft style
    Parrot: Ooo! Ooo! Me too! Me too! Hey, wait up guys!

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

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

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

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

    5. Re:I can't believe it! by epine · · Score: 1

      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 busy looking under the JIT compiler's skirt, it can't get anything done. Hardly a panacea.

      These "Java moments" are livable, but I wouldn't discourage anyone from trying a different approach.

    6. Re:I can't believe it! by popeyethesailor · · Score: 1

      Interestingly, Opera's new ECMAscript engine has a register-based byte-code instruction set.

      http://my.opera.com/core/blog/2009/02/04/carakan

    7. Re:I can't believe it! by Anonymous Coward · · Score: 1, Insightful

      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 Linux VMM is a bit more liberal in letting memory hang around. (Though Eclipse is likely to be a bad test case. The SWT framework isn't as optimized on Linux as it is on Windows. Try running Netbeans on both and see the difference.)

      If you think about it, there's no conceivable way that slower CPU execution can lead to long, intermittent pauses of the type you describe. Poor Virtual Memory Managers, however, are an exact fit.

      Windows VMM has been improperly tuned for years now. Microsoft has not recognized that modern PCs have a LOT more memory, leading to excess swapping. Vista supposedly makes an effort to fix this issue, though I have not personally tested it.

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

      --
      Javascript + Nintendo DSi = DSiCade
    9. Re:I can't believe it! by chromatic · · Score: 1

      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 reallocate the registers so there's no overhead of even passing parameters and receiving arguments.

      --
      how to invest, a novice's guide
    10. Re:I can't believe it! by angel'o'sphere · · Score: 1

      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 considering is the IDE from Oracle.

      In daily work CodeGuide e.g. is 100 times faster than Eclipse, but lacks the plugins.

      angel'o'sphere

      --
      Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
  8. yeah right by Anonymous Coward · · Score: -1, Troll

    Parrot is a twinkle in Larry Wall's eye and you know it.

  9. Perl 6 reference implementation by oldhack · · Score: 1

    So there is a spec for Perl 6? Now there is something novel from Perl camp.

    --
    Fuck systemd. Fuck Redhat. Fuck Soylent, too. Wait, scratch the last one.
    1. 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.
  10. 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.

  11. 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 Randle_Revar · · Score: 1

      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.

      --
      Climate Progress - Hell and High Water
    4. Re:VM question by Anonymous Coward · · Score: 0

      What does Parrot do that other VMs can't

      Magic Cookies.

    5. Re:VM question by Anonymous Coward · · Score: 0

      For one thing, it's a genuine open-source project. The design and specification are controlled by the community, not by Microsoft or Sun.

      For another, it's tailored to the needs of dynamically-typed languages. The JVM sucks for this, while Microsoft's DLR is of little interest because it's Windows-only and probably patented up to its eyeballs (unlike the CLR, it's not an open standard).

      On a technical level, Parrot is interesting because it uses registers (like a real-life processor), where most other VMs are wholly stack-based. In theory this may make it faster; in practice it's probably just a curiosity, given how much money Sun and Microsoft have invested in optimising their offerings.

    6. Re:VM question by Anonymous Coward · · Score: 0

      How about comparing it to other open source frameworks like LLVM and C--?

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

      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.

      --
      - oZ
      // i am here.
    9. Re:VM question by Anonymous Coward · · Score: 0

      Java 7 introduces a new bytecode (InvokeDynamic) to improve support for dynamic languages on the JVM. It will be interesting to watch the situation develop, hopefully parrot will bring increased competition.

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

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

    13. Re:VM question by Trepidity · · Score: 1

      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 to the JVM, which would allow 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).

      --
      10 PRINT CHR$(205.5+RND(1)); : GOTO 10
    14. 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.
    15. Re:VM question by ChunderDownunder · · Score: 1

      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 and prototyping a new language independent vm.

    16. Re:VM question by Anonymous Coward · · Score: 1, Insightful

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

    17. Re:VM question by Anonymous Coward · · Score: 0

      Pynie? more like Py-not:

      Pynie: a Python compiler for Parrot.
      >>> def f(): pass
      >>>
      >>> f()

      ok, that worked...

      >>> def f(x):
      syntax_error at line 1, near "def f(x):\n"
      >>> def f(x):
      syntax_error at line 1, near "def f(x):\n"

      uhh, yeah, that's nothing like how Python works at the command line... I can't define functions?

      >>> 1+2

      uhh, ok, let's not actually be useful and print the result.

      >>> print 1+2
      3

      there we go, now we're getting something that's working.

      >>> import sys
      No result object

      uh-oh, import sys doesn't work?

      >>> dir()
      >>> print dir()
      Null PMC access in get_string()

      ok, I was expecting something here...

      >>> locals()
      >>> print locals()
      Null PMC access in get_string()

      and here...

      >>> print globals()
      Null PMC access in get_string()

      and here...

      >>> for i in xrange(40): pass
      too few arguments passed (1) - 3 params expected

      ok, so I can't do a simple loop w/ an xrange.

      >>> for i in range(40): pass
      >>>

      Oh, cool, I can do useless loops with range. Let's expand on that:

      >>> for i in range(40):
      syntax_error at line 1, near "for i in r"

      Oh, no multi-line statements again.

      Ok, let's see how it preforms, let's run pystone, the simplest Python benchmark:

      No result object
      current instr.: 'pynie;PCT;Grammar;item' pc 86 (src\PCT\Grammar.pir:87)
      called from Sub 'pynie;Pynie;Grammar;Actions;stringliteral' pc 106182 (src/gen_actions.pir:4249)
      called from Sub 'pynie;Pynie;Grammar;stringliteral' pc 65316 (src/gen_grammar.pir:24667)
      called from Sub 'pynie;Pynie;Grammar;literal' pc 62423 (src/gen_grammar.pir:23499)
      called from Sub 'pynie;Pynie;Grammar;atom' pc 79972 (src/gen_grammar.pir:30259)
      called from Sub 'pynie;Pynie;Grammar;primary' pc 77604 (src/gen_grammar.pir:29390)
      called from Sub 'pynie;PGE;OPTable;parse' pc 1995 (compilers/pge/PGE/OPTable.pir:566)
      called from Sub 'pynie;Pynie;Grammar;is_test' pc 92325 (src/gen_grammar.pir:34896)
      called from Sub 'pynie;Pynie;Grammar;in_test' pc 91282 (src/gen_grammar.pir:34501)
      called from Sub 'pynie;Pynie;Grammar;not_test' pc 90880 (src/gen_grammar.pir:34347)
      called from Sub 'pynie;Pynie;Grammar;and_test' pc 89781 (src/gen_grammar.pir:33934)
      called from Sub 'pynie;Pynie;Grammar;or_test' pc 88926 (src/gen_grammar.pir:33616)
      called from Sub 'pynie;Pynie;Grammar;expression' pc 87449 (src/gen_grammar.pir:33070)
      called from Sub 'pynie;Pynie;Grammar;expression_list' pc 67291 (src/gen_grammar.pir:25508)
      called from Sub 'pynie;Pynie;Grammar;expression_stmt' pc 35202 (src/gen_grammar.pir:13186)
      called from Sub 'pynie;Pynie;Grammar;simple_stmt' pc 33932 (src/gen_grammar.pir:12744)
      called from Sub 'pynie;Pynie;Grammar;stmt_list' pc 3753 (src/gen_grammar.pir:1391)
      called from Sub 'pynie;Pynie;Grammar;statement' pc 3480 (src/gen_grammar.pir:1285)
      called from Sub 'pynie;Pynie;Grammar;file_input' pc 1685 (src/gen_grammar.pir:603)
      called from Sub 'pynie;Pynie;Grammar;TOP' pc 536 (src/gen_grammar.pir:118)
      called from Sub 'pynie;PCT;HLLCompiler;parse' pc 665 (src\PCT\HLLCompiler.pir:400)
      called from Sub 'pynie;PCT;HLLCompiler;compile' pc 428 (src\PCT\HLLCompiler.pir:301)
      called from Sub 'pynie;PCT;HLLCompiler;eval' pc 920 (src\PCT\HLLCompiler.pir:519)
      called from Sub 'pynie;PCT;HLLCompiler;evalfiles' pc 1275 (src\PCT\HLLCompiler.pir:688)
      called from Sub 'pynie;PCT;HLLCompiler;command_line' pc 1470 (src\PCT\HLLCompiler.pir:789)

      This is Python?

    18. Re:VM question by master_p · · Score: 1

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

    19. Re:VM question by shutdown+-p+now · · Score: 1

      DLR is already available separately for existing .NET versions. That's how IronPython works today.

    20. Re:VM question by shutdown+-p+now · · Score: 1

      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?

    21. Re:VM question by angel'o'sphere · · Score: 1

      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 Parrot uses a 3 register operations model (like ARM processors do) or a 2 register operations model (like the 68k family).

      There is a wiki pedia article about the classification of "machine codes" in 0 register, 1 register (6502 etc.), 2 register (68k etc.) and 3 register (ARM, and I think SPARC and PowerPC as well, not sure though).

      Bottom line stack based machines have the highest code density, that means very small executables (basically one byte only, hence the term byte code) while 3 register machines have the worst code density (basically one byte each for opcode, operand 1, operand 2 and destination register).

      OTOH if you only build an interpreter (and not a JIT) a 2 or 3 register machine executes its byte code faster, as you don't need to carry and manipulate a stack pointer with you.

      The code is usually interpreted like this:
      JCM/CLR like bytecode:
      stack[sp-1] = stack[sp] * stack[sp-1];
      sp--; // such an interpreter can be optimized by carrying 2 top of stack pointers, to eliminate the "sp -1" part.

      3 Register Machine:
      reg[dest_ptr] = reg[src1_ptr] * reg[src2_ptr];

      OTOH the 3 register machine has it slightly harder to decode the op codes. When I was young built several different VMs in UCSD Pascal, the stack based one was significantly slower, I don't remember but I think it was about 50%.


      The JVM bytecode spec defines a Turing-complete machine. Why isn't dynamic dispatch implemented in it?

      Sorry this turing completeness sentence you often hear on /. meanwhile goes on my nerves. Are you sure you know exactly what it means? It reminds me on all those guys referring to the laws of thermodynamics in every physics thread and never had a physics course in school.

      Anyway: JVM and CLR byte codes have operations like: call virtual method "doSomething". This instructs the virtual machine to check (oops, not really, see below at **) if the class of the object on top of the stack has a method called "doSomething", and it checks wether the next "objects" or "values" on the stack match the method signature. IFF that is the case, the method is looked up and called. The JVM was designed with security and byte code verification in mind. During class loading those opcodes are examined and if you call a non existing method you already get an error during class loading/byte code verification. (**) In other words, during runtime you don't have to perform checks, as this happened already at class loading time.

      In a dynamic language (with a different VM suiting to that language) you don't have the above byte code as you absolutely don't care at load time if methods exist or not. In JVM speak such a bye code could look like: call dynamic method "doSomething".

      Now the point (and idea behind dynamic languages to one extend or the other) is, that you assume the method does not exist. So you can not verify anything during load time. So you always check during execution at the point where an invocation happens what you want to do. Most of the time you can find the method and proceed just as in a normal JVM. Sometimes you don't find it, but you know the object/class did provide a hook, e.g. a method _dynamicDispatch(String methodName, Object[] args). If that is the case, you call that one. Depending on the language such a hook could exist on the object (not class) level as well. If even this fails

      --
      Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
  12. Compiler for Perl? by Futurepower(R) · · Score: 1

    Slightly off topic: Is there a compiler for Perl, that is not based on bytecode, and therefore is difficult to decompile?

    1. 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.'"
    2. 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
    3. Re:Compiler for Perl? by chromatic · · Score: 1

      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 for decoding obfuscated Perl.

      --
      how to invest, a novice's guide
    4. Re:Compiler for Perl? by Goaway · · Score: 1

      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

    5. Re:Compiler for Perl? by Anonymous Coward · · Score: 0

      It's impossible to read Mandarin, it's a spoken dialect. Chinese is the written language. Of course, they do have the simplified and traditional versions of written chinese.

    6. Re:Compiler for Perl? by chromatic · · Score: 1

      It's impossible to read Mandarin, it's a spoken dialect. Chinese is the written language.

      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!

      --
      how to invest, a novice's guide
    7. Re:Compiler for Perl? by Phroggy · · Score: 1

      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 without any trouble, but since the subset of the language you learned isn't the same as the subset of the language some other guy learned, you won't be able to read his code, and he won't be able to read yours.

      Once you've advanced to the point of learning the entire language and can wrap your brain around all of the syntax, only then does reading other people's code become feasible.

      And then, of course, there's deliberate obfuscation.

      #!/usr/bin/perl

      use strict;
      use warnings;

      my $q='XyLEoNgGmGjkrhPrrJtctlhe,auesenaoOmCnEfc';
      for(sort split''=>substr$q,11,22,'Kfkz'){my$d=ord
      substr$q,0,1,'';print"\e[".(ord uc chr $d^64).chr
      (($d&32)/32+67)if($d<122);print}print"\n"#phroggy

      --
      $x='S24;r)>63/* h@<5+oZ)32"5cz';$me='phroggy'x$];
      $x=~y+ -xz+\0-Tx+;print$_^chop$me for split'',$x;
    8. Re:Compiler for Perl? by Eric+Smith · · Score: 0, Redundant

      I wrote a two-pass cross-assembler in Perl some years back, but I still can't make heads or tails of most Perl code I see. It seems like a write-only language to me.

    9. Re:Compiler for Perl? by Anonymous Coward · · Score: 0

      That's a third party library that marshals and unmarshals into a bytecode format that has nothing to do with the way Perl actually represents things internally.

    10. Re:Compiler for Perl? by Anonymous Coward · · Score: 0

      Dear sir,

              Respectfully, fuck off. If you want to build opaque closed systems please stay away from my languages.

    11. Re:Compiler for Perl? by mevets · · Score: 1

      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?

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

    14. Re:Compiler for Perl? by Anonymous Coward · · Score: 0

      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.

    15. Re:Compiler for Perl? by Phroggy · · Score: 1

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

      --
      $x='S24;r)>63/* h@<5+oZ)32"5cz';$me='phroggy'x$];
      $x=~y+ -xz+\0-Tx+;print$_^chop$me for split'',$x;
    16. Re:Compiler for Perl? by Phroggy · · Score: 1

      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 Perl:
      print "New: $foo\n" if($foo=~s/foo/bar/g);

      Compare to a comparable line of JavaScript:
      if(foo.match(/foo/)) document.write('New: '+foo.replace(/foo/g,'bar')+"\n");

      Clearly, the Perl code is more concise, and I would argue easier to read for anyone who knows the language, but if you don't know the language, what does the ~ do? What do the letters s and g mean? In JavaScript, as long as you know the object method syntax, you can look up String.replace() and learn about its arguments.

      --
      $x='S24;r)>63/* h@<5+oZ)32"5cz';$me='phroggy'x$];
      $x=~y+ -xz+\0-Tx+;print$_^chop$me for split'',$x;
    17. Re:Compiler for Perl? by chromatic · · Score: 1

      ... but if you don't know the language, what does the ~ do?

      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 perldoc perlfunc, perldoc perlop, and perldoc perlsyn, or look them up online. (Where do you look up the /g flag for the JavaScript example?)

      --
      how to invest, a novice's guide
    18. 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;
    19. Re:Compiler for Perl? by Anonymous Coward · · Score: 0

      You'd think that, not knowing the language. The truth, though, is that every conversation in Mandarin ever spoken has gone something like this;
      "Hello!"
      "Pardon?"
      "I'm sorry, what did you say?"
      "Could you repeat that?"
      "My apologies, but I didn't quite catch that last part. Could you say that again?"
      "... Oh bugger it, I give up. Damn your soul, chromatic, may your rice rot and your chopsticks poke you in the eye!"

    20. Re:Compiler for Perl? by chromatic · · Score: 1

      That sounds like every encounter I've ever had with Emacs Lisp.

      --
      how to invest, a novice's guide
    21. Re:Compiler for Perl? by jonadab · · Score: 1

      > In my Perl example, you have to recognize that ~ is actually part of
      > 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 even the most basic parts of the language before trying to read stuff written in it, the equivalent of trying to read Russian without bothering to learn the Cyrillic alphabet first. Get a life.

      Perl is not hard to read. Perl is *easy* to read. It's clear, concise, and expressive.

      Lisp is harder to read than Perl.

      --
      Cut that out, or I will ship you to Norilsk in a box.
    22. Re:Compiler for Perl? by jonadab · · Score: 1

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

      --
      Cut that out, or I will ship you to Norilsk in a box.
    23. Re:Compiler for Perl? by Phroggy · · Score: 1

      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 PHP is better than Perl - quite the opposite - but lazy n00bs can figure out PHP more easily than Perl.

      --
      $x='S24;r)>63/* h@<5+oZ)32"5cz';$me='phroggy'x$];
      $x=~y+ -xz+\0-Tx+;print$_^chop$me for split'',$x;
  13. 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.
    2. Re:Parrot 1.0.0 Released by Anonymous Coward · · Score: 0

      He's pinin' for the fjords!

  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.

    1. Re:The original Parrot was an April Fool's joke by Anonymous Coward · · Score: -1, Flamebait

      Joke's on them because Perl is now considered a legacy language and nobody cares about parrot.

    2. Re:The original Parrot was an April Fool's joke by mj41 · · Score: 1

      See Perl 6 and Parrot links - chronological catalogue of more than 500 links. Full Parrot and Perl 6 related history.

    3. Re:The original Parrot was an April Fool's joke by Anonymous Coward · · Score: 0

      Perl is now considered a legacy language

      Considered by whom?

    4. Re:The original Parrot was an April Fool's joke by outZider · · Score: 1

      The same douchebags that think PHP is enterprise.

      --
      - oZ
      // i am here.
    5. Re:The original Parrot was an April Fool's joke by Anonymous Coward · · Score: 0

      Well people in the real world tend to use PHP, yes. Not sure what other point you were trying to make?

    6. Re:The original Parrot was an April Fool's joke by Anonymous Coward · · Score: 0

      The biggest douchebags are the ones who think 'enterprise' means anything.

    7. Re:The original Parrot was an April Fool's joke by DuckDodgers · · Score: 1

      www.indeed.com is a search engine to look through several different job sites. They have 18,000 Perl developer openings listed.

      The language is far from dead.

    8. Re:The original Parrot was an April Fool's joke by aevans · · Score: 1

      what makes you think it's not still just a prank?

    9. Re:The original Parrot was an April Fool's joke by pileated · · Score: 1

      Thanks for the reminder! That was an enjoyable few days.

  15. The lesson from this by Anonymous Coward · · Score: 0

    Be very careful with your April Fool's jokes. They may someday become reality.

    1. Re:The lesson from this by Randle_Revar · · Score: 1

      Hopefully next up: Google moon base

      --
      Climate Progress - Hell and High Water
  16. Benchmarks by FunkyELF · · Score: 1

    Hurry up and get the languages that target it up on http://shootout.alioth.debian.org/

    1. Re:Benchmarks by mj41 · · Score: 1

      No plans to measure Parrot VM on Q6600 (alive part of shootout.alioth.debian.org). There is related discussion https://alioth.debian.org/forum/message.php?msg_id=181415

  17. Mono by tepples · · Score: 1

    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, but then it wasn't released until 2004.

  18. Perl 6 before end of century? by cruff · · Score: 1

    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.

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

      There is Perl 6 release each month.

  19. Larry said it best... by Anonymous Coward · · Score: 0

    Post-Modernism was a reaction against Modernism. It came quite early to music and literature, and a little later to architecture. And I think it's still coming to computer science.
    -- Larry Wall

  20. Voom! by Anonymous Coward · · Score: 0

    They must have pulled the nails that held it to its perch!

  21. Congrats Parrot Team! by BeforeCoffee · · 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

  22. Parrot development goals for each major release by Cochonou · · Score: 1

    The next goals are outlined here.
    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)

    1. Re:Parrot development goals for each major release by aevans · · Score: 1

      So if practical usability is targeted for 12.0, then we'll have another 6 years to wait, if everything goes well?

  23. Dr Sbaitso ? by freaker_TuC · · Score: 1

    Dr Sbaitso, are you back?

    --
    --- I am known for the ones who want to find me on the net. Is that a privacy risk or a privilege? One might wonder..
  24. :) I wish I had another mod point for you. by toby · · Score: 1

    n/t

    --
    you had me at #!
  25. I just don't get it by sgt+scrub · · Score: 1

    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 installed as well as Perl, Python...? I know I have to be misunderstanding the whole thing. That, or Parrot is a lot of overhead for a small increase in speed.

    --
    Having to work for a living is the root of all evil.
  26. Cross-Language Code Reuse by sonamchauhan · · Score: 1

    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
    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 to bridge the social barriers between the camps of language advocates, but you never know, maybe I'm underestimating Larry Wall's social engineering skills.

    I'd love to have a VM that let me use my old Lisp code, and old Perl code, in a new Java program. ... and there have been similar 'Ask Slashdots' earlier
    http://www.google.com/search?q=site:slashdot.org+personal+language+reuse

  27. Perl was cool when U2 was cool by aevans · · Score: 1

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