Beefy Boxes and Bandwidth Generously Provided by pair Networks
"be consistent"

Re^3: A great talk on Perl6

by raiph (Chaplain)
on Apr 03, 2014 at 04:24 UTC ( #1080885=note: print w/replies, xml ) Need Help??

in reply to Re^2: A great talk on Perl6
in thread A great talk on Perl6

Hi emilbarton,

A quick clarification. First, Rakudo (well, NQP really, but let's call that an implementation detail for now) not only already targets the JVM as well as Parrot but is generally at parity or better feature wise when running on the JVM.

(And Rakudo on MoarVM is generally at parity with or better than Rakudo on JVM. The first release of Rakudo Star (a bundle including the compiler and modules) that supports these three backends will likely ship about one month from now.)

I'm not sure what you meant by your why questions. Are you suggesting Perl 6 should itself be a lower level language? Or that the compiler should target a lower level language? Something else?

Rakudo targets NQP. NQP in turn targets various backends. If your question is "why NQP?", please watch Patrick Michaud's excellent explanation of where NQP came from, where it fits in, and where it's going at YAPC NA 2013. (I recommend you start at 6 minutes in and watch at least the next 5 and a half minutes.)

Replies are listed 'Best First'.
Re^4: A great talk on Perl6
by emilbarton (Scribe) on Apr 03, 2014 at 13:57 UTC
    Thank you very much for these explanations, I don't know much about compilers and virtual machines so it's a bit difficult for me to sustain my suggestion. I was just comparing Perl6 with Java and thought that as Java programs could be compiled independently of JVM, i.e. run as C or C++ executables, it would be nice if Perl6 had this possibility too. But now I have a doubt about this possibility in Java, maybe I've just interpreted wrongly some compilation steps I had to do with some Java programs.

    Could NQP or another compiler produce also binary executables (not bytecode intended for virtual machines)? After listening to your link I wonder if this is possible, or if I understand enough of what is going on under the hood to continue this discussion. Sorry for everything silly then.
      > Could NQP or another compiler produce also binary executables (not bytecode intended for virtual machines)?

      One of the main problems with such ideas is to underestimate the dynamism of languages like Perl or JS.

      Just think of the need to have the whole compiler backend to simulate eval.

      Thats why one ends up using a VM with JIT compiler, like V8.

      And of course those can be bundled into a stand-alone executable.

      So the answer depends on the definition of "binary executable".

      Cheers Rolf

      ( addicted to the Perl Programming Language)

        Right, thanks. I didn't think about eval.
        You could use a specializing compiler which does Futamura projections to generate specialized executables, like PyPy does.

        But don't hold your breath for Rakudo to do that, because MOAR is more of the same "let's write it in C then shove a JIT up its arse" crap that doesn't work.

        But dynamic features such as eval could be compiled so as to target an external virtual machine or even the Perl5 interpreter.
      Rakudo can't do that because...

      Well perl-6 can't do that because you can't run perl-6 without a runtime to figure out things like method dispatch and to manage garbage collection and other things. Someone could write a linkable library to provide that but that would only delay perl-6 actually coming out so GET RIGHT ON THAT #perl6!

      Rakudo can't do that because it uses a modified Xeno's Paradox for its development process: every time it gets halfway to completion, someone decides to start a port to yet another backend (or rewrite something else from scratch).

      Java programs could be compiled independently of JVM ... now I have a doubt about this possibility in Java

      I don't think you can do that. Tools like Excelsior JET or exe4j are distributed with, or install, a JVM. Afaik tools that compile to native code do so via a JVM.

      Could NQP or another compiler produce also binary executables (not bytecode intended for virtual machines)?

      In theory, yes, but why? I see plenty of downsides and no upsides. What would you hope such an approach would achieve?

        In Wikipedia I read : "There exist also compilers emitting optimized native machine code for a particular hardware/operating system combination." E.g. GCJ.

        > What would you hope such an approach would achieve?


        Many thanks for your answer, but as I told you, things are beyond my understanding from now on.
        At least two reasons, Ralphie-boy. 1 to avoid rewriting all of your code when the perl-6 spec changes or Rakudo breaks backwards compatibility yet again. 2 to avoid having to depend on whatever the flavor du jour VM is THIS month.

        Maybe that's just one reason. To prevent the beer-obsessed attention deficit development process of perl-6 from breaking your production code.

        Of course that means you're right. You won't hear me say this often, Ralphie-boy, but you're right. There's no point. Why not just use a language that exists? One with developers who know how to deliver working software that doesn't break every month? Good point.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://1080885]
[usemodperl]: i even tried to run perl again from inside script with qx and the working one liner: nada
[Corion]: Maybe the Perl you try stand-alone and the Perl you run are different?

How do I use this? | Other CB clients
Other Users?
Others meditating upon the Monastery: (6)
As of 2018-06-23 12:14 GMT
Find Nodes?
    Voting Booth?
    Should cpanminus be part of the standard Perl release?

    Results (125 votes). Check out past polls.