MoarVM/NQP strengths (was: What might be Perl 6's strengths)
MoarVM/NQP strengths (was: What might be Perl 6's strengths)
Posted Jul 23, 2015 1:46 UTC (Thu) by dvdeug (guest, #10998)In reply to: MoarVM/NQP strengths (was: What might be Perl 6's strengths) by raiph
Parent article: An interview with Larry Wall (LinuxVoice)
As Joel Spolsky said: "All non-trivial abstractions, to some degree, are leaky." Is that not the origin of the phrase "leaky abstraction"?
Posted Jul 24, 2015 0:31 UTC (Fri)
by raiph (guest, #89283)
[Link]
Ugh. Thank you for calling me out about this and doing it gently.
Prudence suggests I stop right here. But I was trying to convey something useful when I wrote the nonsense "non-leaky abstraction" and I want to have another go.
----
In 1992, Kiczales proposed a principled, general solution to the problem later popularized by Spolsky. My TL;DR version would be "build atop [something like] the CLOS mop".
http://www2.parc.com/csl/groups/sda/publications/papers/K...
----
Perl 6 adopts Kiczales' solution wholesale. CLOSish mop mechanisms drive everything from the high level down to as close to the metal as the underlying systems allow.
In particular, the NQP layer implements its abstractions of run-time VM features, and object and function interfaces with other languages, using NQP meta objects.
http://edumentab.github.io/rakudo-and-nqp-internals-cours...
----
When I used the ill begotten phrasing "non-leaky abstractions" I meant "abstractions that can, in principle, be relatively easily tweaked by users so they give correct and performant results -- ie don't leak -- for a given use-case".
> string-using code over a VM that uses NFG and a VM that uses UTF-16 is going to be able to tell the difference; either Perl6 code that expects NFG will be incredibly slow on the JVM, or calling other JVM languages is going to involve a conversion of every string.
First, let me note that I personally don't expect to see Perl 6 *officially* supporting running on the JVM for at least another year.
I think you chose well to pick the NFG abstraction as being especially prone to leakage in the sense of serious performance ramifications when Perl 6 is running on the JVM and especially when one is passing strings back and forth between Perl 6 and another JVM language.
One mitigation is that code that doesn't use character level operations, eg just copies whole strings, compares whole strings, passes strings back and forth between Perl 6 and some other JVM language, etc., could just use some type that `does Unicodey` with an appropriate encoding, eg UTF-16, rather than using Strs (NFG strings).
But yes, it's going to be interesting to see how NFG on JVM pans out. :)
MoarVM/NQP strengths (was: What might be Perl 6's strengths)