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

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!

NV: How does that sound for  a B-movie scenario: dead C programmers return as zombies and get back at the high-level programmers!

JW: How many brains will they eat before segfaulting?

NV: So what is Perl 6’s place in the programming world? What niche can it excel at?

JW: For one, I suspect there will always be text to be transformed, unstructured data to be untangled, and so forth. Perl 6 is strong at this: grammars bring structure to parsing problems and let you get from text to data structure easily, and the range of tools for slicing and dicing that data are immense.

One of the things I find most pleasant about working with Perl 6 code is how easy it tends to be to refactor and evolve. Depending how far you want to go, a quick code sketch can be grown into something more structured – perhaps with classes and roles if needed –  and for added safety you can add in type constraints. Not just boring ones, like “it’s an Int” –  thanks to subset types you can be very expressive.

I think it’s hard to predict exactly what niches a general purpose language will find itself in, however. I mean, it’s not like Perl was designed from the outset to be good for web programming, but when the need came Perl was there and had the ingredients.

Perl 6 has a lot of ingredients to offer. The language seems to sell itself rather well, even if the implementations aren’t all the way there yet. So I’m looking forward to see what people will cook up with it, as we gradually remove more and more of them adoption barriers.

NV: You’re a polyglot speaking Perl  and C#,  hacking on compilers and VMs, teaching, travelling, giving talks at conferences – you seem tireless!   Are you an android that thinks in binary and lives on a limitless power source? Where do you draw that energy from and how do you recharge it?

JW: No, I’m decidedly human with plenty of fragilities. And sometimes, I very acutely feel that. I suspect the most important thing is that I just really enjoy a lot of the things I do. Giving talks is something I really enjoy doing; it gives me energy at some level. All the same, however much you like it, work has a tendency to be, well, work. And eventually, there’s a need to recharge.

I tend to do that by taking  holiday  where I can spend a lot of time outdoors, because my work sadly keeps me indoors a lot. The Swiss Alps are an almost perfect escape, offering hours of beautiful hiking followed by a hearty meal, a nice pint, and some good rest.

NV:  Nowadays there is a lot of buzz around Perl 5 and 6 with the likes of p2, p11, Moe, Perl 7, Perlito, ports to JVM and now MoarVM. Are we witnessing a fallout, separatism, or a diversified attempt of the Empire to strike back and reclaim the throne of the programming Universe?

JW: I think we’re witnessing a community applying the “There’s More Than One Way To Do it” principle to itself. I think it’s tempting to worry about over-diversity, but I find it heartening that the community is of a nature where instead of throwing about ideas as just words, we actually tend to take those words and rectify them into concrete software. This in turn helps us better understand what going in these various directions would look like.

I don’t know where all of these projects will be in 5 years, 10, years, 15 years. But I don’t find myself worrying about it too greatly either. At the end of the day, it’s about producing good technologies that solve problems, and hopefully finding some joy in doing so. Inevitably, some things will work out well, others won’t. But there doesn’t have to be winners and losers. We can, as a community, learn much from every one of these efforts, and that knowledge will leave us richer overall.

 

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