It’s August, which means that many of Europe’s Perl programmers will be looking forward to their largest annual conference. This year YAPC Europe takes place in Kiev, Ukraine from 12-14th August. Let’s take a look at what’s in store for the attendees.
People will start to congregate on Sunday 11th. Some of the early arrivals will be there for the Perl 6 hackathon which will be taking place during the day. Others will just be aiming to be there in time for the pre-conference meet-up – which is always a good opportunity to catch up with friends that you haven’t seen since the last conference.
The conference itself starts on Monday 12th. The important business starts immediately with the announcement of the venue of next year’s conference. That’s followed by Larry Wall’s keynote. After a coffee break I’m giving a talk about Perl’s first 25 years. After that, the conference splits into three tracks and, inevitably, talks will clash and you won’t be able to see 
everything that interests you. I think I’ll see Salve Nilsen talking about the Grassroots community, but Aaron Crane’s talk on Redis is also pretty tempting and the only reason I’m not going to see Léon Brocard’s Syncing social media and feeds with IMAP is because I saw him practise it at a London.pm meeting a couple of weeks ago – it’s a really interesting talk.
After lunch, I’m planning to see Jon Jenson’s Adventures in Perl packaging, because that’s an area I’m particularly interested in, but the other talks look just as interesting. Later in the afternoon Herbert Breunung’s Perl 6 OO vs. Moose sounds fascinating. Monday will end with the first unmissable session of Lightning Talks.
First thing on Tuesday, Zefram will be talking about API design, using DateTime as a counterexample. Knowing Zefram’s opinions on DateTime, that’s going to be well worth seeing. Over the next two sessions there are two talks about Dancer which were very tempting, but I think I’ll be seeing DrForr on DevOps and Curtis Poe’s talk Agile Companies Go P.O.P. In the next session, I’d recommend Tom Hukins’ talking about logging. Luckily, I’ve already seen it, as I’m speaking at the same time about Matt’s PSGI Archive.
After lunch there’s a big clash for me. I’m torn between Vyacheslav Matyukhin talking about Questhub and Leon Timmermans talking about Module::Build (or, rather, his replacement for Module::Build). I probably won’t decide between them until the last minute.
The afternoon finishes with Matt Trout’s annual State of the Velociraptor talk and another session of Lightning Talks. Both of these will be essential viewing. But that’s not the end of the day. This is the evening of the traditional conference dinner – which this year takes the form of a river cruise.
On Wednesday morning, StrayTaoist’s perl 5 is to Shakespeare as p3rl6 is to txtspk lol sounds fun, but Igor Zaytsev’s Perl-JavaScript interoperability with JavaScript::V8 might be more useful. After that Andrew Shitov is chairing a discussion on Perl versioning. Should Perl 6 use a completely different name and let Perl 5 use the number 6 for its next major version?
Later in the morning, Peter Rabbitson’s SQL metaprogramming – non-ORM uses of DBIx::Class sounds interesting. And also Zefram is back with more time pedantry in Why timezones are difficult.
After lunch, I’ll be listening to Alex Balhatchet’s talk on Growing a Perl team and Kersten Puschke talking about oEmbed – a technology I feel I need to know more about. In the final session I’ll be torn between Curtis Poe’s Testing with Test::Class::Moose and Smylers’ A Survival Guide to Handling Contributions from Non-Techies. Then there are a few more Lightning Talks and some closing business. And that will be that for another year.
As always, it looks like it’s going to be great conference. I hope to see you there. If you see me, then please come up and say hello.
Dave Cross is the owner of Magnum Solutions Ltd, an Open Source consultancy company based in London. In 1998 he started london.pm which has grown to be one of the largest Perl Mongers groups in the world. He nominally led the group until September 2001. Between August 2002 and June 2006 he was the Perl Mongers User Groups Co-ordinator for the Perl Foundation. Dave is a regular speaker at Perl and Open Source conferences and is often invited to present tutorials alongside the main conference. He is the author of “Data Munging with Perl” (Manning, 2001) and a co-author of “Perl Template Toolkit” (O’Reilly, 2003). You can follow him on Twitter at @davorg.
We’re going to Amsterdam this November – will you join us?
SharePoint Connections Amsterdam 2013 will take place at the Meervaart Theatre in Amsterdam on the 19th & 20th November 2013. We’re attending and we’d love to see you there.
The Mervaart is a working theatre and it looks like a great venue. We haven’t attended this conference before, but it came highly recommended to us by our author Mirjam Van Olst who is also speaking at the event – thanks Mirjam!
What’s on offer?
The conference offers SharePoint Developers, Infrastructure Specialists, Architects, IT Managers, Business and Power Users sessions about SharePoint 2013 and Office 365. The sessions are delivered by SharePoint and Office 365 MVP’s, expert independent trainers and authors, as well as Microsoft Professionals.
Of course, most importantly, some of our authors are also speaking – you’ll get to hear Dan Holme, Mirjam van Olst, Penelope Coventry and Steve Fox amongst the great speaker line-up. We’ll be there with books for sale on SharePoint and a host of other topics, and you may even be lucky enough to get a copy signed by one of the authors attending.
We said we’d love to see you there and we meant it – we have arranged with the organisers for you to receive a 10% discount on registration using code LA734. Early bird pricing ends 31st August www.nccomms.com/sharepoint_connections #SPCon13
Congratulations go to Anna Martelli Ravenscroft who has been presented with the Frank Willison Memorial Award this year for her outstanding contribution to the Python Community, which includes her volunteer work at both PyCon and OSCON and her public speaking.
Anna has a background in training and mentoring. She brings a fresh perspective to software development with a focus on practical, real-world problem solving, usability and the concrete benefits of diversity. Anna has spoken at both PyCons and at OSCon about diversity and outreach efforts in the Python community and in open source communities more generally. She tirelessly volunteers as an organiser at many of these conferences and is a familiar face at their registration booths. She has also served on the PyCon and OSCON programme committees.
Anna, who graduated in 2010 from Stanford University with a degree in Cognitive Science, was the first woman member of the Python Software Foundation.
She has published several articles and co-authored the second edition of the Python Cookbook with her husband, Alex Martelli.
Python is not her only interest. At the last EuroPython Anna was spotted knitting a lovely hat for her step-daughter and on another occasion gave Josette a great recipe for sauerkraut.
The Frank Willison Memorial Award for Contributions to the Python Community is given annually to a person judged to have made an outstanding contribution to the Python community. The award was established in memory of Frank Willison, a Python enthusiast and O’Reilly editor-in-chief, who died in 2001.
O’Reilly Media presents the award annually at OSCON, the O’Reilly Open Source Convention. The recipient is chosen by O’Reilly Media in consultation with Guido van Rossum and delegates of the Python Software Foundation.
“Contributions can encompass so much more than code. A successful software community requires time, dedication, communication, and education as well as elegant code. With the Frank Willison Memorial Award, we hoped to acknowledge all of those things.” – Tim O’Reilly
The videos from the talks at EuroPython 2013, Florence are now available on YouTube. Thanks to the organisers, I am able to show you some of these talks. To start with, we have Alex Martelli’s keynote “GOOD ENOUGH” IS GOOD ENOUGH! As I am sure you are aware, Alex is a key person in the Python community.
You are looking at this video with the permission of Python Italia, organizer of EuroPython for the last three years.
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
It is now time to say goodbye to Florence, the city that hosted EuroPython 2013. I would like to tip my hat to the PyCon Italia team for putting on such a fantastic conference. EuroPython has been hosted in Florence three years in a row now, with this year being the biggest and best – in my opinion – of the seven EuroPythons that I have had the pleasure of attending.
EuroPython has always been the conference to attend if you would like to learn of new technologies, tricks and libraries in the Python community through the varied talks that are on offer. Most of the talks are practical in nature, giving you an overview of how to employ a library or system, or how a particular technical challenge was addressed. Personally, I will be using material I learned in the talks on password handling (T. Waldman) and ElasticSearch (D. Matthews), while I found the talks on the use of IPython in the classroom (A. Lehman), static analysis (D. Jemerov) and machine learning (S. Shankar) to be informative and interesting.
The talks were chosen by a community voting process that took place online via the http://europython.eu website. As a consequence, talks that have practical value and present information of interest to the Python community will do well here. I submitted a talk myself, which was ultimately – and understandably – rejected due to being oriented towards pure research. The talks that made the cut covered a very wide variety of topics, ranging from web development to augmented reality, from security to education.
EuroPython 2013 had a relaxed and amiable atmosphere. The attendees like to have a good time, so most people don’t take things too seriously. There is entertainment a-plenty to be had from lightning talks, amusing anecdotes between talks, and presenters doing generally nutty things to ensure that they and their products are remembered! I recall Larry Hastings’ lightning talk in particular in which he laid out an ambitious plan to address CPython’s GIL, prompting Alex Martelli to lead the audience in a chant of ‘The GIL Must Go!’
Besides the talks, the hallway track gave everyone the opportunity to meet and socialise over coffee. For the past three EuroPythons this has been excellent Italian espresso that I will miss sorely now that I am on my way home. Many attendees – myself included – consider the hallway track to be one of the most valuable parts of a conference, as you can discuss material more directly related to your own work with fellow Pythonistas. It’s also the place to meet potential employers, collaborators or business partners (probably the best place in Europe for such meetings, come to think of it). It is always a pleasure to make new friends and go to dinner with them in the evenings.
The PyCon Italia team members have always been extremely competent in the art of putting together and running a fantastic conference. Everything worked smoothly; the website was easy to use – it’s designers could teach a lot of web developers a thing or two – and admission on Monday morning was quick and easy. After that everything was smooth sailing. The conference Wi-Fi worked well too; an impressive accomplishment when you consider the challenges involved in providing wireless internet access to 900 net-addicted computer geeks. The venue was fantastic, providing ample space, along with an overflow room with TVs and headphones for over-subscribed talks; a nice touch I thought. Besides fantastic Italian espresso, the food and wine provided at lunch was great; easily the best conference food I have had. The conference meal this year was an outdoor barbeque. I thought that this was a very appropriate choice of event, as it gave people plenty of space to mill around and socialise. Personally, I wouldn’t mind if outdoor events became a regular occurrence (hint hint) :)
It’s all done now so – sadly – it’s time to say good bye to Florence after three fantastic years. Next year its ‘Guten Tag Berlin!’ I am excited to experience EuroPython in a new location and venue in 2014, and I hope you can join us!
I am currently a research associate / assistant tutor at the University of East Anglia, where I work on a historical document management system. I have been an avid Python programmer since 2005. My interests centre around programming tools and 3D graphics. I am the author of the gSculpt 3D modelling program and ‘The Larch Environment‘, a software development environment research project.
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 forecasts 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.
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 scepticism. 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: In a previous interview, Moritz Lenz shared with us that Parrot’s main mistake was that instead of focusing on satisfying Rakudo’s needs, it aimed to become a general platform for dynamic languages, something that ultimately made life hard for the Rakudo implementers. Has MoarVM learned from that, or is interoperating with other dynamic languages on the agenda?
JW: Well, there’s one dynamic language we’re very interested in interoperating with, and that’s Perl 5. For now, we’ll take the expedient path of making 5/6 interop work nicely rather than trying to generalize the whole thing into some beautifully abstract set of interop primitives. But it’s not just a case of running Perl 5 on MoarVM – though the v5 module work that’s going on may allow that to – but rather a case of integrating the existing Perl 5 interpreter.
On the question of being a general platform, though, if you look at the VMs that do successfully host multiple languages today, they’ve typically started by hosting one language really well. My interest is in making MoarVM do Perl 6 really well. If, some years down the line, that makes it an attractive target for other languages… well, that’s just fine. But I’m most certainly not thinking about the needs of other languages when taking design decisions for MoarVM.
All of this said, Perl 6 has a LOT of language features. And the NQP compiler tool-chain that we build Rakudo on is rather rich and powerful. So there’s nothing to really stop people using it to write a compiler for another language today.
Indeed, writing a compiler once that targets the JVM, MoarVM, and so forth for free could be an interesting proposition. Naturally, I’ll be happy if people pick up the tools and enjoy creating other language implementations with them. But my focus when designing and building MoarVM is quite firmly – “What do I need for Perl 6?”
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 organisation’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: Can or will there be alternative tools that could emit bytecode for MoarVM? For example could MoarVM be considered a possible backend to Perlito?
JW: The bytecode format is specified, and the goal is for it to be declared stable a little way down the line, so there’s no real reason why not. One thing I decided fairly early on is that MoarVM will not have is an official intermediate language or assembly language.
The code generation we do today for the NQP to MoarVM translator goes directly from a tree data structure down to bytecode, skipping the costly generating and reparsing of text. So if you want to do that from outside of MoarVM, you’d actually need to generate bytecode. Or maybe somebody will build a little assembler.
NV: The I/O infrastructure is currently based on ARP.Why are you considering a move from ARP to libuv? Is it because of the node.js-like asynchronous execution capabilities? How will those be integrated into the platform?
JW: Yes, it’s for the asynchronous I/O. Rakudo’s lack of support for that has been a common and very legitimate complaint for a while, and I know it’s an adoption blocker for some, so clearly I’m interested to deliver something there. We’ll be able to do it on the JVM, and MoarVM should certainly handle that case too.
We could build what we need from scratch, but why? I mean, things like the object model and JIT compilation make sense to be done in a very custom way. They’re the core domain, the places that MoarVM can shine by doing what Perl 6 needs efficiently. For async IO, there’s no reason to recreate something when we simply want to do well there, not discriminate MoarVM from the market by somehow doing async IO better.
Of course, that doesn’t mean at the language level we shouldn’t have a better story. But at the runtime level, taking something battled-hardened and integrating it seems the way to go.
As for how, we have a rather free hand there, since Rakudo doesn’t support async IO yet
The more interesting challenges will probably be in making async IO really nice to do at the Perl 6 language level, rather than the VM level stuff, which will certainly have it’s challenges but are more “hidden”.
NV: So how is the Rakudo-to-Java interoperation utilized on the JVM? Because of that relation can Perl 6 run on Android?
JW: The first of those is a currently work in progress, and I’m optimistic we may ship support for calling into Java code in the next Rakudo compiler monthly release. It will be interesting to see how that gets used; I know various people have expressed interest, so I’m mostly waiting to see what they will do with it.
As for Android, one current blocker is our use of the new invokedynamic instruction. Once we get a “don’t use indy” compilation option, or invokedynamic becomes available on Android, I suspect that with a little effort it should be possible.
Part 3 which concludes the interview will be published next week
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
Simon and Helen C from the O’Reilly UK office are making their way to Madrid today for TechEd Europe, which starts tomorrow. They’ll be at stand 16, and have a jam-packed schedule of author signings taking place throughout the week. Here’s the list of scheduled signings – please note that the local Spanish time is used:
Tuesday
- 12.30pm – Andrew Bettany signing ‘Exam Ref 70-687: Configuring Windows 8’
- 6.30pm – Marco Russo and Alberto Ferrari signing ‘Microsoft Excel 2013: Building Data Models with PowerPivot’ and ‘Microsoft SQL Server 2012: Analysis Services: The BISM Tabular Model’
- 7.30pm – Matt Masson signing ‘Microsoft SQL Server 2012 Integration Services
Wednesday
- 1pm – Ben Howard signing ‘Microsoft Project 2013 Plain & Simple’
- 1.30pm – Ed Wilson signing ‘Windows Powershell 3.0 Step by Step’
- 4pm – Ivan Sanders signing ‘Business Intelligence in Microsoft SharePoint 2013’
Thursday
- 12.30pm – Julie Lerman (O’Reilly’s own!) signing her Programming Entity Framework series
- 1pm – Penny Coventry signing ‘Exploring Microsoft SharePoint 2013: New Features & Functions’ and ‘Microsoft SharePoint 2010: Business Connectivity Services’
- 2pm – Dejan Sarka signing ‘Training KIT: Implementing a Data Warehouse with Microsoft SQL Server 2012’and ‘Training Kit: Querying Microsoft SQL Server 2012’
- 2.45pm – Paolo Pialorsi signing ‘Microsoft Sharepoint 2013 Developer Reference’, ‘Build Windows 8 Apps with Microsoft Visual C++ Step by Step’ and ‘Build Windows 8 Apps with Microsoft Visual C# and Visual Basic Step by Step’.
Friday
- 2pm – Mark Russinovich signing ‘Windows Interals’ Parts 1 and 2
- 2pm – Aaron Margosis signing ‘Windows Sysinternals Administrator’s Reference’
Hope everyone has a great TechEd Europe! Helen C and Simon are looking forward to seeing you at our stand.
Jim Webber, GOTO Distinguished Speaker, discusses narratives and graphs with Ryan Slobojan. Topics covered include his first talk given at a Trifork conference, conferences attended, the benefits of giving talks at conferences, the importance of narratives and history, the challenge of first discovery, commonalities between REST and graphs, the Web as a graph, Semantic Web, graphs and triples, polyglot persistence, Neo4j, drivers of graph adoption, applications of graphs, and combining genetic algorithms and graphs.
For more information about the GOTO Conference Series: http://gotocon.com
Dr. Jim Webber is Chief Scientist with Neo Technology, where he researches novel graph databases and writes open source software. Previously, Jim spent time working with big graphs like the Web for building distributed systems, which led him to being a co-author on the books REST in Practice (2010) and Graph Databases (2013). Jim is active in the development community, presenting regularly around the world. His blog is located at http://jimwebber.org and he tweets often @jimwebber.