All about Perl 6 – interview of Jonathan Worthington (Part 1 of 3)

The latest news 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 getting the definitive answers to these intriguing questions, we’ve managed to get hold of Jonathan Worthington for an exclusive interview. Jonathan 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 short 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: What about C#’s injected into-dynamic language features? Do they really make a difference?

JW: Are you thinking of things like the ‘dynamic’ keyword in C#? If so, I can only say that my experience “in the wild” is that most developers don’t use that. I’m not sure we should be too quick to say, “Oh, it’s because C# programmers refuse to consider dynamic typing”, however. Many people I teach are barely using Linq or lambda expressions, which showed up in C# a release before “dynamic”.

The “Ooh, that’s actually useful” moment people tend to have with dynamic is when I show them how, with the appropriate library, you can use dynamic typing in C# to dig into JSON documents, just like you would do in JavaScript. “Oh, we don’t have to build a load of types to deserialize this stuff into!” So, mostly it’s showing people how things are actually useful.

NV: So broadly speaking, what can experience in Perl offer a C# programmer and vice versa?

JW: “The limits of my language mean the limits of my world.” – Wittgenstein.
Now, I’m pretty sure he was talking about natural languages, but I think it goes for programming languages too. And, just like a natural language has a community and a value system around it, so do programming languages.
Perl and C# may both be multi-paradigm languages, but they do feel rather different to write. I found myself approaching problems in different ways in each of them. But I’m quite sure working in both has influenced the way I write each of them.

I think in the Perl to C# direction, you bring an understanding that not everything needs to be expressed as methods on a class, fitting into some type hierarchy. It’s OK for things to be “just a subroutine”, or “just a function”, or “just a quick thing you do with a regex” – because that’s exactly what some problems need.

Going the other way, I’d say you perhaps come with a little more appreciation of where adding type annotations into programs can help. I’m excited about what we’re doing in Perl 6 in this regard with gradual typing. And, if you get into C#’s Linq stuff really well, you start to see more operations as list processing, which Perl is rather good at. Perl 6 especially so.

And that’s a win, because chains of list operations are easy to read – the next thing’s input is the last thing’s output – as well as nice and functionalish.

NV: So let’s go back to the beginning and talk about Rakudo, JVM, and MoarVM. Was the move of porting Rakudo to the JVM planned, or was it driven by Parrot’s deficiencies?

JW: Having Rakudo also running on the JVM has been of interest to us for years. Python is on the JVM. Ruby is on the JVM. Where is Perl? What if Perl fits your problem, but you are only allowed to deploy things on the JVM at your organization? The modern reality is that talking about “run everywhere” is no longer just about operating systems and CPUs. Some of those “everywheres” are virtual machines now.

So there’s a lot more to it than, “Parrot has deficiencies”. Even if Parrot had worked out incredibly efficient, getting Perl 6 onto other runtimes would still have been important. The JVM should give us a speed boost for a bunch of workloads. The numbers so far are encouraging. Startup time, on the other hand, is pretty awful. I doubt we can ever get that really low on the JVM.

But perhaps the most important thing for the Perl 6 project overall is that the JVM has very well tested, battle-hardened threads support. We really, really need to nail down those aspects of Perl 6. Once the porting is over, that’s where I expect a lot of my focus will go. So, the JVM support helps fill in a bunch of the puzzle pieces.

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.

Part 2 to be published next week

 

Nikos Vaggalis holds a BSc in Computer Science and a MSc in Interactive Multimedia. Professionally, he is engaged in the development of database applications and anything related to the RDBMS. He is a SQL aficionado and codes in both Perl and C#. As a journalist, he writes articles, conducts interviews and reviews technical IT books