There a lot going on in the Perl World. Nikos Vaggalis talks to Jonathon Worthington and asks: Why yet another VM?  How does Perl 6 stack up against other modern languages like C#?  Is there any room in the programming world for it, after all?

The latest news in the Perl world is that Parrot Virtual Machine is no longer the only one enjoying Rakudo’s exclusivity. Not long after Rakudo had been successfully ported to the JVM a new hosting candidate that aims to change the rules of the game, MoarVM, went public.

All that activity has raised a lot of questions regarding Parrot, Rakudo and the direction Perl 6 is heading for:

Is Parrot dead?

Why yet another VM and what’s up with the JVM?

How does Perl 6 stack up against other modern languages like C#?

Is there any room in the programming world for it, after all?

For definitive answers to these intriguing questions, we interviewed Jonathan Worthington who is the architectural mastermind and primary driving force behind not only Rakudo’s implementation, but also all the projects revolving around it, such as NQP, the port on the JVM, and now the brand new MoarVM.

As if simultaneously engaging in these cognitively demanding activities was not enough of a Herculean task, Jonathan also maintains a full time job, teaching classes in – what else? – programming.

The interview is not just confined to Perl-ish matters, and Jonathan also shares his expert views on a number of complementary topics, such as C#’s dynamic features, and whether C still has any relevance in programming.

NV: Wherever your name is mentioned, Perl 6 springs to mind. Did you really jump into Perl 6 straight away or did you already have a background in Perl 5?

JW: I certainly used Perl 5 for many years before I was involved with Perl 6. I learned a lot from Perl. I came to it, like many, for web programming. My family suggested I get a summer job. I didn’t want to stack shelves, and it was the kind of time when it was easy to get work for building web stuff, so I reckoned I better figure out something you could do web programming with.

At the time, Perl was a pretty obvious choice for that. I got myself a copy of the Camel book expecting to learn a new language, and came out of it with a new appreciation for programming.

Perl was my first exposure to regexes, higher order programming, closures, and probably a dozen more things I simply didn’t know about before. This was before I went off to study Computer Science, of course. I was mostly a self-taught programmer. I even learned to indent my code “the hard way!”

I was, but a Perl 5 user, though. I discovered Perl 6 around the same time I was increasingly specializing in compilers, language semantics, type systems and so forth during my computer science degree. I got curious. Then I ended up contributing. I expected to do just a patch or two… well, I guess I’ve done a few more than that by now.

NV: Do you think that Perl is still a viable option for web programming when now it has to compete with the likes of PHP, Ruby on Rails etc. which own the biggest slice of the pie?

JW: For sure. The nature of the web and web programming has changed considerably since I hacked together my first CGI script almost 15 years ago. But Perl’s web story most certainly hasn’t stood still in that time.

There are multiple modern ways to do web programming with Perl: Catalyst, Dancer, Mojolicious. Honestly, I don’t do a lot of web programming these days; I feel like I’ve already done enough of it for a lifetime – but I do attend plenty of Perl conferences, and talks on all of these show up pretty often. They look modern, and pleasant.

So yes, Perl is a very, very viable option in my view. A cool and trendy option? Well, maybe not that. But the Perl community is blessed with a lot of good people who build a lot of good stuff. I value that.

NV: Aside from mastering Perl, you make a living out of teaching, classes in C#, amongst other subjects.  How did you come up with that combination, given that those two languages are diametrically opposed?

JW: If we were talking about C# version 1, back in 2000 or so, I think I’d have agreed with “diametrically opposed”. C# then felt like “another Java”, and while I greatly respect a lot of the things built in Java, I find it a difficult language to efficiently express myself in.

However, C# went places I really did not expect. These days, C# is a multi-paradigm programming language. Granted, it expects your major building blocks to be classes, but within that you’ve a lot of opportunities for higher order programming, declarative programming, and so forth.

Put that together with type inference and the result is a language I find fairly expressive.

Granted, I don’t find it expressive to the same level as Perl, especially Perl 6. But I think it’s fair to say that C# has – though I suspect much of the .Net community would look at me oddly for saying this – has become more Perl-y over the years.

As for teaching programming languages, I think having an understanding of what makes languages tick and how they fit together is important. Closures, lazy evaluation, types, objects – yes, the details vary (greatly in places) between C# and Perl 6. But knowing how these things are implemented means you can explain them pretty well for most languages.

So in that sense, I find my roles complement each other. It makes sure I can still explain to people the kinds of things I’m working on implementing!

NV: Work on the JVM port is successful and well underway, so why are we already looking at a new VM, MoarVM? Why the need to implement, for example, a GC and JIT for MoarVM when these components are readily available on the JVM? Ultimately, do we need yet another VM, or is it the case that the existing families of VMs cannot cope with Perl 6′s programming model?

JW: One of the turning points in Rakudo’s development was 6model, the name I gave to an objects implementation designed with Perl 6′s specific needs in mind. As part of the design for that, I thought a lot about optimizations – JIT included – and ensuring it would be possible to actually build a 6model implementation from “bare metal” as well as in terms of existing VM constructs.

This was initially with the idea of getting the work integrated into Parrot someday. But the more I looked at it, the more difficult that seemed. 10 years of development led by different architects at different periods of time (each of them with good ideas, I should add) led to a fair amount of baggage, as it would in any software project. With some quiet encouragement from others, I started considering what it would take to take the 6model design and put an “r” in it. So that’s where the name comes from: Moar = Metamodel On A Runtime. MoarVM is a place where we’ll be able to do “native” implementations of various Perl 6 constructs, with the idea being that a very close semantic match can lead to efficiency.

Additionally, there will be people who want to use Perl 6, but who really don’t want to use the JVM to run it. Maybe they don’t want the overhead, maybe they don’t like it, maybe they are doing one-liners or other things where you mostly care for start-up time.

One fear in all of this, of course, is that this new diversity of backends would stretch an already stretched development team. In fact, the result has been quite the opposite. People, who never really cared for a Perl 6 on Parrot but really like the idea of Perl 6 on JVM, have shown up and contributed. MoarVM has drawn in a relatively disjointed set of people. So my feeling is that if there is this much diversity in potential contributors, it will exist for potential users too, since I imagine the vast majority of people contributing to Perl 6 are doing so because they want to use it for more and more of their day-to-day work.

NV: What does that say about the JVM’s project’s life expectancy? Will it run in parallel with MoarVM’s development? Does all this forecast Parrot’s demise?

JW: The JVM is playing that difficult “second backend” role. Going from one target VM to two exposes all kinds of assumptions, such as places where things are not sufficiently well abstracted and so forth.  Such abstractions are not easy to design because you’re not only thinking about how to hide differences, but how to convey enough semantic information downwards in order to allow good code generation.

Having the second VM that is already mature and well established is a huge help. OK, I did manage to segfault the JVM thanks to the odd invokedynamic bug I managed to hit upon. But by and large, if something is wrong, I can be pretty sure that the JVM itself will not be to blame. So, the JVM porting leads the way.

That naturally means we’ll get to a rather complete Rakudo on JVM some way ahead of getting there with MoarVM. The work on the two is going on in parallel. The JVM work has already blazed the “how to port Rakudo” trail, so really the MoarVM project complexity is much more tied up with the VM itself, not with working out how to get things ported to it.

As for Parrot: I think it’s worth remembering that Rakudo, along with the module ecosystem out there, runs on Parrot today. Of course, we aim to get there with the JVM and MoarVM in the coming months. But whatever happens with Parrot, those using and developing Rakudo will probably still be running it on Parrot for some time to come. So that’s the short term. In the mid-term, the user base will decide what they prefer to run Rakudo on, and the answer will vary between users. We’ve no plans to go ripping out Parrot support once we run on the JVM and MoarVM. The path genuinely is multi-backend.