Beefy Boxes and Bandwidth Generously Provided by pair Networks
There's more than one way to do things

Re^7: Think Perl 6 (new book)

by raiph (Chaplain)
on May 19, 2017 at 16:02 UTC ( #1190645=note: print w/replies, xml ) Need Help??

in reply to Re^6: Think Perl 6 (new book)
in thread Think Perl 6 (new book)

Thank you. So I'm now thinking your overall opinion might be stated as something like "It seems that Perl 6, or at least the Rakudo Perl 6 compiler, will almost certainly always suffer from the same implementation problems as Java, or at least javac, due to its architecture, for many of Perl 5's most popular use cases."

Are these problems you see specific to particular VMs like the JVM? Or do you see the same sorts of problems applying even to, say, LuaJIT and its VM, for much the same reasons?

If LuaJIT's VM is OK, what are the main things about it that makes the LuaJIT project a fundamentally different and potentially acceptable architectural approach, in your view, for the use cases you focus on?

If you think that some VMs, in some scenarios relevant to you, can be a good thing, what are the main things that lead you to think that MoarVM misses the mark?

Replies are listed 'Best First'.
Bytecode VMs are not a panacea Re^8: Think Perl 6 (new book)
by hippo (Monsignor) on May 19, 2017 at 16:42 UTC
    If you think that some VMs, in some scenarios relevant to you, can be a good thing

    I can't immediately think of any scenario relevant to me where a VM would be a good thing, no. I do however see other situations where they might be: phones, embedded, applets, etc. Hence my comment about the orthogonal use cases.

    I have barely used Lua so am not qualified to comment on the particulars there. Conversely, I have battled frequently against the JVM and will be a very happy camper if I never have to deal with it or its like ever again. The problems with it which are so bad that it is unsuitable for pretty much any of my types of work include:

    • It is glacially slow
    • It requires constant care and attention in both invocation and running
    • It does not recover gracefully
    • It is an unbelievable resource hog
    • It isn't compatible with other versions of itself (despite write-once-run-anywhere being one of the principles of Java as a language)*
    • It isn't even compatible with other versions of itself from the same vendor*
    • It doesn't integrate well with non-java libs and utilities*

    While those I've marked with an asterisk are quite possibly "features" of the JVM only, the others do appear to be equally applicable to other VMs.

    Those areas I mentioned where VMs might be a boon (phones, embedded, applets) are no doubt ripe for Perl6 when it hits maturity. The rest, not so much. Those of us who work elsewhere would very much like to keep on using Perl instead and not have to explain constantly why Perl6 isn't an upgrade.

      So does Scala suffer from the same problems because of the JVM?
Re^8: Think Perl 6 (new book)
by Anonymous Monk on May 19, 2017 at 21:00 UTC
    what are the main things that lead you to think that MoarVM misses the mark?

    It shows no signs of learning anything from Javascript VMs.

    And Lua is a very different language from Perl6.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://1190645]
[GrandFather]: It's either lines that your browser won't split (no white space) or nodes with <pre> tags which ought to be code tags
[GrandFather]: I haven't noticed the problem for a while, but it can be hard to find the nasty node. If you do find it, consider it and with luck a janitor will fix it

How do I use this? | Other CB clients
Other Users?
Others wandering the Monastery: (3)
As of 2017-05-24 00:56 GMT
Find Nodes?
    Voting Booth?