Beefy Boxes and Bandwidth Generously Provided by pair Networks
Clear questions and runnable code
get the best and fastest answer
 
PerlMonks  

Perl 6... do we need another vm?

by jfroebe (Vicar)
on Sep 04, 2006 at 03:44 UTC ( #570993=perlmeditation: print w/ replies, xml ) Need Help??

First off, let me express my deep respect for the individuals working on Perl 6 and their work so far. This is not a bashing or anything of the sort. I'm just asking a question that I've had for sometime (I'm rather neutral on this).

My understanding of Perl 6 is that the perl code will be compiled to a byte code and run in the VM runtime. The idea is that the vm will be able to run just about any language that can be thrown at it given that there is a parser available.

Currently, there are only two vm environments with any considerable following:

  1. .NET vm With the Mono project coming into its own, .NET is no longer just for Microsoft operating systems but can be run on just about anything.and the .NET vm.
  2. Java vm No description is really necessary ;-)

My question is whether Perl 6 really should revolve around yet another vm or should it be aligned to either one of the vm's above?

I know Active State has made some progress with running Perl 5 in the .NET vm though the $$ price is rather... well, I'm not able to justify the price to the fiancee (soon to be wife in a month from now).

I'm just asking because I'm having trouble understanding the need for another vm but am more than willing to understand before my brain is shutdown (after wedding my brain will be replaced with a bowl of oatmeal so my married friends tell me;-)

Jason L. Froebe

Team Sybase member

No one has seen what you have seen, and until that happens, we're all going to think that you're nuts. - Jack O'Neil, Stargate SG-1

Comment on Perl 6... do we need another vm?
Re: Perl 6... do we need another vm?
by duff (Vicar) on Sep 04, 2006 at 04:27 UTC
Re: Perl 6... do we need another vm?
by jdtoronto (Prior) on Sep 04, 2006 at 05:09 UTC
    I know Active State has made some progress with running Perl 5 in the .NET vm though the $$ price is rather... well, I'm not able to justify the price to the fiancee (soon to be wife in a month from now).
    ActiveState no longer has a .NET product, it was killed off some time ago.

    jdtoronto

      Any pointers? The ActiveState Perl Dev Kit, containing the PerlNET compiler seems to be well and kicking. I guess you mean the Visual Studio plugin that they used to have, but that's not really related. It was just an extension for the Visual Studio IDE.

      BTW, ActiveState PerlNET does NOT compile Perl5 to the .Net bytecode. It just packs the Perl sources to an EXE or DLL and provides the linking between .Net bytecode and Perl , but the Perl code is still compiled and executed by the good old perl engine.

Re: Perl 6... do we need another vm?
by chromatic (Archbishop) on Sep 04, 2006 at 06:17 UTC

    The restrictions on both the CLR (patent worries) and the JVM (Sun has a weird definition of portable that doesn't cover many platforms) make both rather inappropriate from the start.

Re: Perl 6... do we need another vm?
by ambrus (Abbot) on Sep 04, 2006 at 10:23 UTC

    Don't you realize how some people like programming a virtual machine like parrot? If they do, why take away their joy?

      I don't think the OP is asking why people are allowed to make a VM. He's asking why Perl 6 is going to promote it's own VM as the primary platform.

      As you can see in the FAQ linked above, Perl 6 can potentially run on any VM (even one I might decide to write in my spare time). But the primary target is Parrot.
Re: Perl 6... do we need another vm?
by apotheon (Deacon) on Sep 04, 2006 at 18:59 UTC

    NOTE: Emphasized text indicates an edit.

    I notice that none of the people excited about using Parrot (including the FAQ-writer) seem to have addressed issues like maintaining a run-from-source availability of code like we currently have. Once you start requiring compilation to persistent bytecode packages, you lose the ability to just read the program any time you like. I've gotten to like that quite a lot over the years, and I'll miss it.

    I understand why Parrot, rather than JVM or .NET/CLR — what I would like to hear more about is why JIT/interpreter implementation has suddenly become a second-class citizen at best, and more likely a non-citizen entirely.

    print substr("Just another Perl hacker", 0, -2);
    - apotheon
    CopyWrite Chad Perrin

      Once you start requiring compilation to bytecode, you lose the ability to just read the program any time you like. I've gotten to like that quite a lot over the years, and I'll miss it.

      I expect that you'll rapidly see the evolution of reverse compilers - just like you did in the Java world - much easier to implement with high level VMs like Parrot.

        That's a comforting thought, and I suspect you're right, but there's still no substitute for running directly from source code.

        print substr("Just another Perl hacker", 0, -2);
        - apotheon
        CopyWrite Chad Perrin

      Once you start requiring compilation to persistent bytecode packages, you lose the ability to just read the program any time you like.

      I don't understand what you mean. You can run bytecode or source code with Parrot right now. I've done both today.

        I'm sure a lot of people paying for Perl will require bytecode compilation, especially if they're planning to distribute it as product, so the statement stands as written to some extent. I was not, however, aware that Parrot would run directly from source. I was under the impression it was a bytecode-only VM. Thanks for the info.

        print substr("Just another Perl hacker", 0, -2);
        - apotheon
        CopyWrite Chad Perrin

Re: Perl 6... do we need another vm?
by revdiablo (Prior) on Sep 04, 2006 at 19:50 UTC
    My understanding of Perl 6 is that the perl code will be compiled to a byte code and run in the VM runtime. The idea is that the vm will be able to run just about any language that can be thrown at it given that there is a parser available.

    That looks like a pretty accurate description of Parrot's goals, but Perl 6 has a separate set of goals (which are, naturally, not entirely nailed down, and subject to change). One of those is that it should be a language that can, and hopefully does, have multiple implementations. This means the implementation is no longer the spec, as it essentially is for Perl 5.

    The idea has led to many interesting developments. One of the directions that I've recently been excited about is the 6-on-5 stack. That is, an increasing number of bits and pieces of Perl 6 running on Perl 5. There are a lot of benefits I can see to this, and the approach seems very logical and sane. There are already fruits borne of the effort, too, which is a very good sign (for example, see Moose).

    All in all, while the Perl 6 road has been rocky, I think in the end it will produce some good stuff.

      There are a lot of benefits I can see to this, and the approach seems very logical and sane.

      ... except for the reasons why not to build Perl 6 on the Perl 5 VM which are even more valid in 2006 than they were in 2000, namely that Very Few people know how or want to work on the Perl 5 VM and that the Perl 5 VM is complex and obtuse and sprawling and nearly impenetrable to people who don't already know how to work on it.

      (Then again, Simon Cozens and I figured out a way to make continuations work with it and Nicholas and Rafael seemed to agree that it's possible.)

        except for the reasons why not to build Perl 6 on the Perl 5 VM which are even more valid in 2006 than they were in 2000

        Indeed. I didn't mean to imply that 6-on-5 was a good Long Term Solution, just that it was something I thought was a nice consequence of the goal not to be tied to any particular implementation.

Re: Perl 6... do we need another vm?
by badaiaqrandista (Pilgrim) on Sep 04, 2006 at 22:55 UTC

    I think, Parrot is good for evolutionary reason. The world has never seen a vm specifically designed for dynamic language. And with all those new sparkling features in Perl 6, Parrot people will have to design the ultimate vm for dynamic language. Therefore, if Parrot fails, it will become a very good learning process. But if it succeeds, I'm sure it will become a reference implementation for future vm's, and we will surely learn a lot from it.

    I wish the best of luck for the Parrot people. I'd like to help but I haven't got time yet.

    -cheepy-
        Oh, the young'uns, forgetting all about Smalltalk in 1980. {sigh}

        Not to mention Lisp :-)

        Hell - if you've got a Linux box you can still play with Poplog. Lisp, Pop-11, ML & Prolog all compiling down to the same stack based VM, which was in turned compiled down to a RISCish register based VM, which was in turned compiled down to machine code.

        Kid's eh? :-)

Re: Perl 6... do we need another vm?
by harryf (Beadle) on Sep 05, 2006 at 08:51 UTC

    Looking at what Dan Sugalski has been up to recently with tornado, could it be there's another potential Perl 6 VM in the making there? From it's intro.pod;

    Tornado's a virtual machine geared towards multithreading and vector operations.

    Actually have yet to figure out what the point of tornado is, and whether there's any real potential there. Insight appreciated.

      Actually have yet to figure out what the point of tornado is, and whether there's any real potential there. Insight appreciated.
      What's the point? Well... does it really need a point? It could, after all, be art.

      Whimsey aside, Tornado's a niche VM, by design and intent. Most people don't have the need to run arbitrary small programs against large quantities of data, or to run massively threaded programs in a restricted environment, potentially across a large number of machines (distributing the programs with the data).

      If that's the case, it's a cute little indulgence by a guy with some free time and a few things he feels like fiddling with.

      On the other hand, there certainly are some areas where what it does (when it's finished, potentially before) can be quite handy.

      • It should be good for doing multiple interacting agent work for simulations, where the massive (portable) threading is a win.
      • It should be good for doing real physics simulations where the threading, vector, and distribution should be a win.
      • It should be good for doing configurable crypto, where the decryption program is shipped with the thing to be decrypted. (And really, would you allow arbitrary binary code to run on your machine? In a sandboxed, restricted VM you probably would)
      • It should be good for writing game engine bits. NPC/creature AIs, user-written agents or actions, or suchlike things. (Every object could, potentially, be its own little program interacting with the universe)
      Definitely niche, no question. But it's an interesting niche...
        Most people don't have the need to run arbitrary small programs against large quantities of data, or to run massively threaded programs in a restricted environment, potentially across a large number of machines (distributing the programs with the data).

        Not today, no, but more than yesterday and still more tomorrow.

Re: Perl 6... do we need another vm?
by audreyt (Hermit) on Sep 06, 2006 at 03:40 UTC
    Pugs has targeted multiple VMs (JavaScript, Parrot, etc.) in the past, and we look forward to target more VMs in the future.

    I've worked with CLR and YARV people to explore techniques in targetting them, and indeed both will probably become reasonable targets in their next release. I also plan to find some JVM people and see how much of JRE6 stuff we can use, but I'm not sure it's ready for Perl 6 yet.

    As for Haskell: Pugs and Darcs have pushed GHC to improve its efficiency as a imperative VM, so it is becoming a really viable target for Perl 6.

    However, with all that said, I think for the next few years, Perl 5 remains the most practical and robust VM to target, which is why Pugs now embeds Perl 5 by default. :-)

Re: Perl 6... do we need another vm?
by husker (Chaplain) on Sep 07, 2006 at 14:49 UTC

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://570993]
Approved by friedo
Front-paged by apotheon
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others drinking their drinks and smoking their pipes about the Monastery: (6)
As of 2014-12-28 07:48 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Is guessing a good strategy for surviving in the IT business?





    Results (179 votes), past polls