NV: Marketing wise, aren’t you concerned that announcing the development of yet another VM for Rakudo Perl will reignite doubt as well as sustain the commotion over Perl 6 and its future?

JW: Yes, though to put it into context, the doubt around Parrot itself has not been especially helpful from a Rakudo marketing perspective either. The reason MoarVM was built in secret up to the point it was revealed, was partly a marketing consideration. Coming out saying, “Well, we have this idea to build yet another VM” would have been rightly met with a lot of skepticism. Saying, “Oh, we have this thing you can already translate and run over 80% of the NQP (a Perl 6 subset used to write Rakudo) test suite on” is a rather stronger position.

So yes, it concerned me. Deciding to work on MoarVM was not easy for that reason and others. Frankly, I didn’t need a third full time job. Don’t get me wrong, I enjoy working on MoarVM, but it’s demanding in terms of concentration and brain cycles. Not to mention that debugging a GC is not exactly a fun evening in. Rather, I did it because, having spent a bunch of years growing an understanding of Perl 6 as a language and how to implement it, I reached the point where the costs of working on MoarVM looked like they could be outweighed by the wins from doing so. Plenty of toil remains to reach the goal, but if the Rakudo developers have shown anything, it’s endurance.

NV: Integrating/embedding the existing Perl 5 interpreter into the platform means that Perl 5 will keep its blood ties to XS and won’t finally get a proper hardware independent VM?

JW: Exactly. The goal of this bit of interop is to make CPAN modules and an organization’s existing Perl 5 investment accessible from Perl 6. You don’t go that far before you hit an XS dependency, so if the goal is to make existing stuff accessible then XS is a non-negotiable. All that said, there is an active effort to implement Perl 5 on top of the same compiler tool-chain that Rakudo is built on top of. It’s early days yet for the work, but it is making good progress.

That bit of work is known as v5, by the way. And it wasn’t something coordinated top-down from those of us already working on Rakudo for years. It was a new contributor who said “Hey, let’s try to make this work!” The good news is that it should be fairly easy to get that effort running on the JVM and later MoarVM also.

NV: The JVM has been primarily designed with statically typed languages in mind. The same goes for the CLR, and that is why the DLR (build on top of CLR) came into existence.  Have you at some point considered the DLR (maybe combined with Mono instead of the CLR) or JVM’s Dynalink, both of which admittedly have a good Meta Object protocol infrastructure, as a potential backend to Rakudo?

JW: One interesting thing to note about Perl 6 is that it’s a gradually typed language, which means the considerations are a little different from if it was dynamically typed. In that sense, VMs which explicitly seek to do both static and dynamic typing well are especially interesting for Perl 6.

I can’t speak too well to the DLR, but I do know that Niecza, the Perl 6 on CLR implementation, went the way of not using it for a range of reasons. By contrast, the JVM’s invokedynamic instruction has been rather interesting from a Perl 6 implementation point of view.

Dynalink is certainly of interest too, in so far as it seems to provide an interesting path to enabling calling Perl 6 code from Java. I’d rather reuse an existing solution than reinvent that wheel. I need to dig into it more deeply to be really sure.

NV: Parrot is a register-based machine and MoarVM follows in its footsteps, so it looks like that this model works best. What are the merits of a register-based machine? Is it more adept to the dynamic type of languages?

JW: It’s a bit easier to build a relatively efficient interpreter with a register-based machine. I think that was one of Parrot’s main reasons to go that way.  Even when you have a JIT compiler, being able to interpret efficiently still matters. JIT compilation takes time: you want to spend the time on hot paths, not on something you hit once in the program’s lifetime.

Having now done the code generation work for register and stack machines (since the JVM is stack based), it doesn’t feel in any sense to me that the dynamic nature of the language has much to do with it. Mostly, I found the register-based code generation a bit easier to do, because in Perl 6 most constructs can show up as an expression.

To take an example, a try block in Perl 6 works just fine as an expression. But on the JVM, the stack must be empty either side of a try/catch construct. So you have to do some work to spill the stack into locals if there’s anything already on it.

I haven’t really come out of all this thinking register machines are overwhelmingly better than stack machines, though – but they are a bit easier on the code generation, which is nice. If you plan to put your call frames on the system stack, the stack approach seems more attractive from that angle. Once you decide you’re not doing that, you could go either way. I chose the easier code-gen, because hey, laziness is a virtue, right?

NV: Interestingly enough, although VMs are more and more embraced, increasingly locking the programmer into the managed world abstracting him away from low level languages like C, most of them are themselves written in C! How would the IT world be affected if a virus outbreak wiped out all C programmers in a day?

JW: Pretty badly, though anybody who managed to reverse engineer the language would probably be able to make some good money training new C programmers!

While such a virus outbreak sounds more like the plot for an awful movie than a realistic concern (though, I would say that because I’m a C programmer), there is some reason for concern: I’m not sure that many people are being taught C these days.

I ask a lot of the people I teach what languages they encountered while studying. Java is up there, but C I don’t hear so much. Now, from the point of view of what’ll land a job, that probably makes sense. But knowing C properly implies knowing how a bunch of low-level things work.

So, perhaps there is something to fear in this regard, even if it’s not a C programmer-eating virus!

A fuller version of this conversation appeared as a three-part series on the JosetteORama blog.

See Part 1

See Part 2

See Part 3

Other Perl-related interviews by Nikos Vagallis:

Perl 6 and Parrot - In Conversation with Moritz Lenz

Perlito - An Interview With Flávio Glock

Niecza - Perl 6 Implemented in .NET 

More Information

6guts - Jonathan Worthington's  blog

Related Articles

Perl 6 Preview Release

In Praise of Perl and the Llama

To be informed about new articles on I Programmer, install the I Programmer Toolbar, subscribe to the RSS feed, follow us on, Twitter, Facebook, Google+ or Linkedin,  or sign up for our weekly newsletter.

 

 

Comments

Make a Comment or View Existing Comments Using Disqus

or email your comment to: comments@i-programmer.info