Damian Conway is one of the key figures in the Perl 6 design team, and the author of Exegeses, the documents explaining the ideas behind the concentrated design decisions reflected in Apocalypses. We talked to Damian during his visit to Amsterdam in March 2015.
Design Backgrounds
Of course, you’ve heard that Perl 6 is going to be production ready this year, finally. Do you believe it can be real?
I believe that it is a feasible outcome. I think that it depends on aspects that we can’t control at all like Larry’s health, and how available Patrick and Johnathan were going to be, and the rest of the development team. I think if we say no unexpected major setbacks and no one becomes unavailable for any reason then I think that it’s quite feasible that we’ll see a 6.0.0 release somewhere between September and December.
When did you hear about Perl 6 and when did you join its development?
Well, I heard that Perl 6 the day it was announced at the conference. It was a very early OSCON that we were at and I wasn’t in the room when they decided to do it, but I heard the announcement made. Then it was a couple of months later that I became involved in design team.
Did you decide to join yourself or were there any other reasons?
I was invited to join.
Invited by Larry?
By Larry. I think it would be very presumptuous for someone who was as relatively new to the Perl community as I was in 2000 to say, “Yes, you should have me on your team,” but when he asked me if I would be involved I was very happy and honored to be, so I said yes.
The Wikipedia defines you with these two rare words: interlocutor and explicator of Larry Wall. Why do we need that kind of person?
That was a role that I fulfilled early in the design project: say from 2000 to about 2008/2009. At the time we were doing the design and creating explanations that were called the “Apocalypses” and these were very detailed design documents of the basic aspects of what we were going to do in Perl 6. The problem is that they were written like design documents. So, they were written quite technically, they were written very shorthand, and they were written assuming that the readers understood everything about Perl 5, so they’re almost like diffs against Perl 5.
They were very detailed as well, but they didn’t really spell out the consequences of these proposed changes and improvements. All they did was say what they were and how they would work. So, I felt that in order for the community to start getting behind Perl 6 there needed to be teaching documents as well rather than just technical documents that experts in Perl could read and understand, or maybe experts in programming languages could read and understand. We needed something that ordinary, everyday Perl 5 developers who were busy with their real jobs using Perl 5 could read and that would take them through some of the consequences of what was being suggested and show them what might be possible. I started creating these documents to make clear to a wider audience exactly what it is that we were trying to achieve.
That role was kind of like translating from the very highly technical way that Larry was thinking about design down to the everyday consequences of what would happen. So, Larry would write the Apocalypse, which would be the document that would describe the language, and then I would write the Exegesis, which would be the document that explained what the Apocalypse meant. This is taken from religious practice as well. You have people writing the official religious documents and then you have people writing explanations of what the heck they’re actually saying…and that was my job at the time. It was entirely appropriate. It wasn’t that Larry wasn’t capable of writing such a document. We all know that Larry is very capable of communicating brilliantly in written text, it was that he was busy carefully writing technical documents and we needed someone who could then translate those into everyday experience and that was one of my jobs at the time.
You mentioned a couple of times the community and the Perl 5 people. Does that mean that those documents were only aimed for people who already programmed Perl 5?
They were mostly aimed at that. They weren’t really aimed at people who were outside the Perl community at the time. I still relied on the fact that people knew Perl 5 to read the document. I didn’t rely on the fact that they knew all the ins and outs in the way that Larry knows Perl 5, but I relied on the fact that they understood what a variable was, and what the difference between an array and a hash and a scalar was, so the documents were written primarily to speak to the Perl 5 community. Which was, at the time of course, the only real Perl community.
Don’t you think it would be different if you aimed just developers, not only Perl developers? Now we only have Perl 6 considered a great thing within the Perl community and it’s something rubbish from outside.
Well, you see I think that, since about 2008, that’s what I have been doing. Not so much in the writing that I’ve done, but in the presentations that I’ve given. Most of the presentations that I’ve given have not been aimed at the Perl 5 community.
For example, last year and this year in Oslo I have been giving lectures that are designed to encourage people who are not part of the Perl community to hear about and learn about and discover all the benefits of Perl 6. I’ve spoken at universities and I’ve spoken in general open source communities rather than just in Perl groups.
I’m doing the same thing throughout Europe as I travel. Wherever I speak I try now not to just speak to the Perl mongers, but I try and find ways to get into other places where I can talk as well. For example at the end of this tour, I’m speaking at CERN in Switzerland and I’m speaking about Perl 6. Although I haven’t told them that’s what I’m speaking about because, as you say, Perl 6 has a bad reputation outside the Perl community, so I just told them that I wanted to talk about transparadigm programming which is what Perl 6 is, and I’ll just talk about Perl 6 and I may not even say that it’s Perl 6 till the very end of the talk.
What’s the reaction of these people outside of the Perl community?
The reaction outside the Perl community is very often, “Wow. We didn’t realize that it was this far along.” Because, of course, whenever I talk about it, I demonstrate it running. “We didn’t realize that OOP could be this easy to do, we didn’t realize that functional programming could be this easy to do, we didn’t realize that regular expressions and grammars could be this easy to do.” They kind of like it.
It’s not yet convincing people to leave JavaScript, or Haskell, or Ruby, or Python, or anything else, but I think that, at least in the regions that I can reach, it is convincing people that Perl 6 (a) is not vaporware and (b) is not a terrible, evil, “even-worse-than-Perl-5” language.
There are also Synopses. Why do we need to have this additional layer of ideas clarification?
Okay, when we started writing the Synopses they were because Larry’s Apocalypse documents were so detailed that it was impossible to keep them all in your head. They were very long and involved and powerful documents, but we needed just summaries so that we in the design team could keep in our head every decision that we already made. When we started doing this we realized these work better as design documents than the big, long, beautifully worded descriptions, or my big, long, beautifully worded explanations. It’s the difference between having “to do” lists with bullet points and writing yourself an essay every morning as to what will happen today. An essay is wonderful as historical document and it’s wonderful for communicating what’s going to happen to everyone else, but in terms of getting stuff done it’s kind of useful just to have bullet points.
So the Synopses took over as the main way of doing it. The Apocalypses and the Exegeses were a way for us, in the early days, to think about the problems and get them down in language. The Synopses are supposed to be: “Look, here is just the summary of the decisions that have been made, without all the explanation about why they were made.” And that’s the difference. The Synopses don’t, most of the time, say why we did it this way. They’re not trying to capture the design philosophy; they’re merely trying to capture the design decisions.
Sister Languages
15 years ago Perl 6 was kind of a next level of Perl 5. Now it’s completely different. Do you think that what we have now is just the result of the 15 years of development or it was initially aimed to be that way as it is today?
I think about a year into the project, when we had assimilated the 361 suggestions that we received from the Perl community, we realized at that point that Perl 6 could not just be the next major release of Perl 5. We realized it could not just be that we needed to fix a few edge cases and change a few things and add in a couple of features. We realized that what people were really asking for was a language that was Perl-ish, that had the philosophy of Perl, that had the approach of Perl, that had the flexibility and the power of Perl, and the convenience of Perl, but which had entire extra layers that Perl 5 never had, probably would never have, and probably should never have.
There was no way to get to what people were asking for, from Perl 5. Perl 5 will never become that and that’s great. I don’t have a problem with that at all. But if you want completely declarative object orientation: that was not something that was easy to put into Perl 5, especially if you wanted it to be object all the way down. That’s nearly impossible to do because Perl 5 isn’t objects all the way down. If you wanted to have lazy evaluation of infinite lists for example, or even for finite lists, that’s not something that you can just layer on top of the existing codebase of Perl 5. That really needs to be designed right down into the core of the language that you’re building.
Similarly with all the different parallelism features that we talked about. All the concurrency features like junctions, like vectorizing of operations and methods, and so forth. You really can’t just layer that over the top. We had two attempts to layer threading over the top of Perl 5 and I don’t think anyone would say that either of them was particularly successful. What we really needed was to design it in from the very beginning, and to design the language so that it could support that. Even if you want to include very powerful functional programming features, it has to be right in the core of the language itself. It has to be designed there from the start or you’re not going to get the performance out of it.
After about a year of wrestling with all of the things that people said that they wanted and said they needed (and all of the things that we wanted…because Larry and I and the other members of the design team had just as many things that we wanted for Perl in the future), we realized that it was going to be not enough just to evolve Perl 5 into that. We really needed to create was a sister language. We needed another language that was in the same family, that had very obviously the same roots, and the same philosophy, and the same culture, but which had a different design…and even a different aim. Therefore, we started thinking of Perl 6 as a new language.
Plus, we realized that one of the things that the Perl 6 design process had done was revitalize Perl 5. One of the great things about the number of people who didn’t like Perl 6 and the idea of Perl 6 and the direction it was heading, was that it enabled them to find the enthusiasm and the energy and the will to come back to Perl 5 and start working on Perl 5 and start developing new variants of Perl 5. If we look at Perl 5 as it is today, with an annual release cycle, and monthly blead releases, and every major release with new and useful and powerful features that are, for the most part, actually diverging a little bit from Perl 6, I think some of that strong community and that strong development that’s reoccurred was simply reaction to Perl 6.
Not all of it. We could point to a huge number of other things, including the P5P developers and what an incredibly job they’re doing, and the fact that we’ve had good leadership in P5P in the last how ever many years you want to count back…a good many years. But having a sibling to compete against injects energy into Perl 5 as well and I think that’s a great outcome. Even if Perl 6 had never actually eventuated, the renewal of Perl 5, and the energy and the ideas that are coming into Perl 5, is a great outcome as well. We’re very, very happy to see both languages moving forward on parallel, but maybe slightly diverging tracks.
The fact that Perl 6 is now incompatible with Perl 5, that’s not the problem anymore?
Not a problem…and I don’t think it was a problem from the very beginning. I think from the very beginning we realized that, if we were going to fix some of the fundamental difficulties that people had with Perl 5, it was going to have to be backwards incompatible at some level. And it turned out that it had to be incompatible right from the syntax up. I mean, I’ve been teaching Perl 5 now for getting on towards two decades and it has never been easy to teach $/@/%. Anyone who learns Perl struggles with that for weeks, or months, or sometimes for their entire Perl programming career. Some people never really get the hang of it.
There was no way we could fix that without breaking compatibility, because we had to change what the sigils meant and how they worked. As soon as you do that…well, they’re almost the signature characteristic of Perl. If you change that, Perl 6 is not going to look syntactically like Perl 5, except by accident.
Once we accepted that we needed to do that, for a one time backwards incompatibility we got so many benefits. We could back out of so many decisions that, in hindsight, turned out not to have been the right decisions. The thing is: Perl 5 continues on with all this backward compatibility, so that’s not actually lost. Perl 6 gets another go, gets a chance to do things slightly differently, in ways that (for some people) will be better.
This sigil issue might be a problem even in Perl 6, where you can assign a scalar, or an array, or a hash to the same $x. Wouldn’t be that a problem for people who would learn Perl 6?
It doesn’t seem to be a problem in Ruby, or Python, or Java, or JavaScript, or any of these languages where you can do this similar sort of thing. Most languages get away with basically one kind of variable, a scalar variable and you put a reference or a pointer (or whatever they like to call it) inside that variable. If people just want to code Perl 6 with nothing but dollar signs, and don’t want to use arrays and hashes directly, we have no problem with that. None at all…and if that makes your life simpler as a Perl 6 developer we’re all in favor of it.
What we wanted to do was make it possible to choose. Perl has always been this: “…more than one way to do it.” In Perl 6 we want there to be even more ways to do it, so that we can be inclusive of a wider community. If you want to escape from JavaScript and don’t want to use it anymore, or if you love Ruby but it frustrates you that it’s hard to do some things in Ruby, then we want you to be able to write Perl 6 in a way that is very reminiscent of your experience in JavaScript or Ruby, and in a way that allows you to leverage most of what you knew about programming those languages…to take that straight over and program in Perl 6. That’s our aim there.
We want Perl 6 to be a much more flexible language than even Perl 5 is. But we want to do it in ways that are safer than allowing you to write source code filters, or just redefine keywords, or something like that. We want people to be able to bring all of their knowledge, all of their experience, and all of their preferences to Perl 6 and still write good code.
That’s the problem in Perl 5. In Perl 5 you can write a functional program, an object oriented program, you can do imperative programming, you can even do “kind of declarative” and “kind of concurrent” programming. But it’s really hard to bring all your knowledge in from the other languages that do those things and still end up writing good, clean, maintainable, readable, understandable, correct code in Perl 5. We’d like it to be much easier in Perl 6 to do that…and that’s kind of our goal.
You published a number of Perl 5 modules in the Perl6 namespace, from the simplest ones like Perl6::Say to rules and grammars. Why do you need that in Perl 5?
Oh, the reason that we needed that in Perl 5 was that Perl 6 was taking so damn long. I’m an impatient kind of person and as soon as Larry said we’re going to have say as well as print I could instantly see how critically important say was. That say is a much, much better tool than print for 70 to 80 percent of the things that I ever want to do with I/O. It’s only a tiny thing, but I do it all the time. Practically every Perl program I’ve ever written had a dozen or more prints in them and practically every one of those prints I had to stick an actual newline on the end of them.
When I saw say, I wanted it now. Not having the patience that many other people have, I decided I want it now, I must have it now. This was back in the time, of course, when we were still at Perl 5.8, where there was no say in Perl 5 at all. I said I can’t wait until Perl 5.10 comes out because we didn’t know at the time if it was ever going to come out, because Perl 5.8 had been there for many, many years now. I said: “How hard would it be to write the module?” So I wrote the module. It was really easy. It didn’t do 100% of what I needed, but it did 95% and people liked it. People used it and it was enough to encourage the inclusion of say in Perl 5.10.
Then if you look at 5.10 there’s a lot of that kind of thing going on. I created the Switch module, which wasn’t in the Perl 6 namespace, but was a Perl 6 idea, and eventually used even the same syntax as Perl 6. It’s where the Perl 6 given/when came from. Eventually, that was so useful, but so poorly implemented, that we got given/when in the (Perl 5) language.
With many of these things, including Perl6::Rules, the regular expression syntax that I tried to bring back to Perl 5, many of the features that were provided in that module are now in Perl 5 regexes. Named captures, independent subroutines. I don’t think they only came about because I made Perl6::Rules; they probably also came about because I made Parse::RecDescent, and then I made Regexp::Grammars. But by bringing those things into the Perl 5 universe, at least to the extent where they were usable, if not convenient, that encouraged the Perl 5 developers to look at these things differently. To say this might actually be useful to have in the language. Not in all cases, but in many cases that happened.
The other thing was: I’m not a Perl 6 partisan. I’m not on Perl 6’s side and against Perl 5. I love both languages. I want both languages to succeed, and become better, and be the best they can possibly be. In Perl 6, that meant being part of the design process and helping out as I could there. In Perl 5, it meant providing the tools so that people would be able to use some of these great features in Perl 5 today.
They were also a really good way of testing out ideas to see if they did actually make sense in the real world deployment before we said: “Yes, they’re definitely going into Perl 6.”
Perl 5 in this case was kind of test platform for some of the ideas?
For some of the ideas, yeah.
Do you have examples of feedback?
The most obvious example is the Switch module. People loved the idea of the Switch module when I first reveled it, because we’d wanted a switch statement in Perl 5 for very many years and we had no way of working out how to do it. The Switch module showed everyone how it could be done, and the feedback was: “this works really well, but it’s kind of confusing in some of the ways that you have to use it.” It was limited by some of the ways that I had to implement it in Perl 5…to make it work at all. and source code filters were really not the way to do it. I think Switch, because it was probably used more than any source code filter, demonstrated why source code filters are such a terrible idea…and that’s why they’re not part of Perl 6 at all.
So, yes, we got useful feedback. The useful feedback was: “Yeah, switch statements are kind of good.” But smart matching, as I had originally conceived it and as it was later put into 5.10, maybe works better in Perl 6 than in Perl 5, because the type system of Perl 6 helps you in a way that we can’t do in Perl 5.
Source code filters, which were how I managed to build many of these Perl 6 modules on top of Perl 5, turned out to be a disaster every single time that they were deployed in real life and that was very good evidence that they shouldn’t exist in Perl 6 at all. And, indeed, also that Perl 5 needed mechanisms to allow the syntax to be extended without source code filters, which is at least some of the reason we eventually got programmable keywords in Perl 5.
First of all we got Devel::Declare, which was it’s own nightmare, although brilliant. Then we got programmable keywords which had the same power and more safety.
I think that those turned out to be useful lessons, both positive and negative, from the same module.
In Perl 6 we will have a built-in mechanism to extend the syntax even during the program execution.
Absolutely, and that mechanism is Perl 6.
Perl 6’s own parser is written as a Perl 6 grammar. So, if you already have that grammar in place, all you need to do is provide a mechanism which allows you to extend the grammar. And, of course, in Perl 6 a grammar is an object-oriented class-type thing, and the rules of the grammar are methods of the class, so you simply say “Ok, I’m going to take the standard grammar, I’m going to inherit it, change some of the rules, or add in new parsing rules, and then install that new parser in place of the original parser.” You immediately get a new extended version of the language, or indeed a complete replacement of the language.
We conceive of Perl 6 as being what we call a “braided” language…like you braid hair. That is, we want Perl 6 to have the ability to flip into different syntaxes (either extension syntaxes or entire replacement syntaxes) in any lexical scope of a Perl 6 program. As long as you explicitly say to start using a different syntax, you should be able to just do it. The long term hope would be that if there was a part of your code that would be better written in say Haskell, or in Python, or in JavaScript, or in Perl 5, then you could literally, within a block, say use Perl 5; or use Haskell; or use JavaScript;, and write that part of the code in that language.
That’s not going to be in Perl 6.0, although we are seeing some modules like the inline Perl 5 module coming out allowing you to do some of that. But ultimately, because the parser for the language is written in the language itself, it means you can change the parser as you need to, without all the problems of source code filtering. Because it’s still a real parser doing the analysis of the code, and you can use all of the features of a parser to do it, rather than just getting the source code and having to try and go through it with regexes to pick out the bits that you want…like you currently have to do with source code filters.
How far a developer can go with modifiable Perl 6 grammar?
I think that we can go way too far if we’re not careful. I think there are virtually no limitations on how far you can go, but I think that there’s kind of a bell curve where adding in some extra features to the standard language would probably improve it for your task, but adding in too many features will just make it too complicated and too difficult. It’s like all things. A moderate amount of enhancement or change in the syntax probably allows you to create a version of Perl 6 that’s better targeted to whatever it is that you’re trying to do, but changing the language too much you lose probably that benefit, because then it’s just completely alien. We want to provide the tools, but we probably also need to provide the education that this is not always the right thing to do.
On the other hand, this will also make it very easy to build your own little DSLs. Ruby itself has demonstrated how useful it is to be able to just run up a DSL, and Python has done the same thing. Okay, I just want a specific language that is just for solving my task. It’s reasonably easy to do that in those other dynamic languages, and indeed in Perl, it’s not all that hard to do. In Perl 6 it is going to be extremely easy to do, because of the sheer power of the grammar mechanism that’s built into the language, and because that you can in fact braid these DSLs in. You can actually have a block that’s written in a completely declarative style that’s only useful for you application, but which makes your application go from being 300 lines to being 5 lines. I think that will be another use.
I think you’re going to see two levels. You’re going to see little tweaks on Perl 6, where people just want to add one little feature that isn’t core. And you’re going to see people go to the other extreme and say: “I want a language that is optimized for my tasks and which then effectively translates back to Perl 6.” Both of those are going to be easier in Perl 6.
Compilers
Initially, when it started with Parrot, Perl 6 was designed to be something that comes with a virtual machine inside. Was that a good choice or not?
Yeah, I think that the decision that Perl 6 would run on top of a virtual machine was a very good choice and is still proving to be a very good choice…even if Parrot doesn’t end up being one of the main platforms that Perl 6 is used on frequently. Because the desire to implement Perl 6 in such a way that it would run on top of Parrot meant that it was relatively easy to put it on top of the JVM and on top of the new MoarVM that’s being developed. It’s probably possible to put it on top of other VMs that might come along in the future, or that we might find to be useful to run it on top of today.
I would say that almost all of the performance improvement that we’ve seen over the last couple of years in the Perl 6 pre-releases has come from being able to run on these new virtual machines. If you run Perl 6 on top of Parrot it runs quite well, but as soon as you run it on top of MoarVM or JVM the performance is just incredible. Because in the very early days we decided that we were going to have this layered approach (which frankly is what everybody does nowadays anyway), and because we had that right from the beginning, these new VMs became feasible targets. I’m not saying it was easy. There was a huge amount of work that was required to make it work, and they did wonders and incredibly work in the implementation team to do that, but it was possible. It was possible because Rakudo had always run on a virtual machine and therefore replacing the virtual machine didn’t mean tearing out all of the tendrils of the implementation from the parser and from the top level parts. There was a relatively clean API between those layers, which meant that it was possible to do that with only a vast amount of work, rather than impossible to do it with any amount of work.
By the way, the Rakudo name is your invention?
Rakudo is a name that I invented, yes. It’s a contraction of “rakuda do” which in Japanese I presume means “The way of the camel”. And “rakudo” itself also means “paradise”. We think that Perl 6 is heavenly, so one of the implementations of it should be at least called Paradise.
Larry said that the only virtual machine that will be supported by this Christmas’ release is MoarVM?
I believe he has said that. I haven’t been following that aspect of that very closely, so I can’t say that for certain. It doesn’t surprise me. Rakudo on MoarVM is more complete in most aspects than on either of the other two machines that it currently runs on. Some aspects are more complete over the JVM, but there are other aspects on the JVM that aren’t as complete. I think MoarVM provides the optimal target for getting something out. If we said we could only release once it runs on all three platforms, then it might never be released. I think focusing now on getting it working on MoarVM and getting MoarVM working quickly enough, and the translation working quickly enough so that it is a competitive alternative to other languages, is important. If Larry has said it’ll only be released on MoarVM that doesn’t surprised me in the least because MoarVM is the furthest advanced of the platforms on which it runs at the moment.
In this context do you consider that Parrot failed, or that was just a test project for further development?
I don’t think Parrot failed at all. There are a number of ways in which Parrot really succeeded. The first of those ways is it allowed us to start implementing nearly a decade ago. If we had to wait for MoarVM or someone to do it on the JVM, we might not have been implementing until the last year or two, in which case we wouldn’t be nearly as far advanced. Furthermore, Parrot showed us what, in fact, was going to be essential for a virtual machine that would run Perl 6 efficiently, and therefore allowed the developers of MoarVM to avoid a lot of dead ends and directions that wouldn’t have been good to go in. If you want to think of it as a prototype then that’s probably a very good way of thinking about it. In the XP sense of it in that you don’t necessarily expect that it’s going to be the final platform, although it may still be one of the final platforms, but you do expect that you learn a lot from doing it, that you get your development up and running, that you get a lot work done, and a lot of experience, and a lot of knowledge which you could then apply to the next prototype.
It may be that MoarVM is not the final VM for Perl 6. It may be that there is never a final VM for Perl 6, it’s just that we eventually migrate to more and more optimal VMs for it. So, no I wouldn’t consider Parrot to be a failure in any respect. Because without Parrot we wouldn’t have Rakudo today.
How do you think, will different big names like IBM or Microsoft ever create a compiler for Perl 6?
I think it’s extremely unlikely that big names like them will ever create a compiler for Perl 6. As far as I know they’ve never created a compiler for Python, or Perl 5, or JavaScript, well JavaScript all right maybe they did, but for Ruby, or any of these other interesting languages they haven’t done that. I don’t see why they would do it for Perl 6 either. I don’t think we need them to do that.
I do think anyone who wants to write their own Perl 6 compiler is very welcome to do. So as long as their compiler passes the test suite, they can call it Perl 6. So, if people want to do it…that’s great.
You might eventually see a Perl 6 implementation running on top of .NET, but whether that will have been done by Microsoft, or by the open source community, I don’t know. We’re happy either way.
Learning Perl 6
There is a Synopsis 26 called “Documentation.” What’s so special about it?
Well, that’s exactly the same purpose as Perl POD. perldoc perlpod for Perl 5 says what the documentation syntax is. If you don’t have that, how can you write the documentation in POD for Perl 5? We decided that Perl 6 needed an enhanced version of POD…for all the reasons that everyone who’s ever used POD already knows about. Which is that POD is a wonderful idea, it’s very very simple…until you want to do anything interesting, in which case you can’t really do it in POD anymore. I was very concerned with documentation, with making it possible to do better documentation for Perl 6, and therefore I did a lot of work in redesigning POD, cleaning it up, making it more orthogonal, making it more powerful, and putting in the features that were missing. For example: tables, which you need in documentation and which aren’t really easy to do in Perl 5’s POD.
There were also lessons that we learned about markup languages. Some markup languages are better than other markup languages and mostly they’re better if they don’t have a whole lot of tags around everything. One of the proposals that we got in the original request for comments for the Perl 6 design was that we go to XML for documentation and, oh boy, I’m glad that we decided not to do that. In fact, I would have said that Perl 6’s POD is more heavily influenced by the kind of textual based languages that we see: like Markdown and Restructured Text, and so forth. It’s still POD-like in the sense that’s it’s more like Perl 5’s POD in the way it uses equal signs on its tags, but many of its features are more like the way you do things in Markdown, just with a bit more markup structure to them than Markdown has.
It is probably impossible to learn Perl 6 in a few days. What’s the best strategy to learn the language?
Well, I would say exactly the same thing is true of Perl 5. I still consider myself to be learning Perl 5, and learning better ways of using Perl 5. I’ve pretty much got the syntax down now, but I think there’s still stuff that I’m learning in Perl 5 all the time. And Perl 6 is exactly the same…only more so. I think that the strategies for learning Perl 6 have to be similar to the strategies for learning Perl 5, which is you don’t start off saying: “Right I’m going to develop and deploy a 5,000 line Perl application.” I’m going to start writing little scripts. I’m going to start just using little features of the language, trying things out, maybe writing a couple hundred lines of object oriented or something like that, but I’m not going to try and migrate 10,000 lines of Perl 5 across to Perl 6 in one big go.
Interestingly, the talk I’m giving here this afternoon is precisely on that. It’s showing people: Look, here’s a little script, it’s a real world script, it’s one that I actually use myself day to day. It’s big enough to be non-trivial, but it’s something that I can explain in 45 minutes and people can see how to do it. And it’s something that you could start out writing. You could say: Okay I’m going to write this, I don’t need to use incredibly advanced features, I don’t need to use the concurrency features, I don’t even need to do object orientation, I’m just going to use the better subroutines and the better regexes in Perl 6 to do something relatively simple. I’m going to learn how to use the sigils correctly in Perl 6 and just do little things.
I think the way that you best learn Perl 6 is by writing Perl 6. It’s true of any language. The best way you can learn it is to start writing in it, but you start writing at the right level…which is I’m going to write a 10 line script, or a 20 line script, and then I’m going to write a 50 line script, then I’m going to write a 100 line program that’s got maybe two classes in it that does something with object orientation, or I’m going to write a 50 line functional programming thing because functional programming happens to be my bag and I enjoy that so I’m going to write in Perl 6.
You start small, and you dip your toes in the water, and you gradually build up your knowledge and your experience and your confidence, and then you say: Well it would be really nice if there was some way of doing this as well, and then you discover, oh, hey they’ve already thought of that and there is this way and now I can learn how to do this. I think the answer is: step by step by step.
It’s quite universal.
Yeah. It’s no different. There’s no magic here. It’s not the magic language that you can just learn in one afternoon. It’s a powerful and sophisticated and very, very rich language and it takes time to learn that. Maybe a lifetime.
On your website, there are four courses for Perl 6. Do you really teach Perl 6 now?
Yeah.
And you are going to expand them?
I am. I hope to have 15 courses for Perl 6 in a couple of years time, but for me as commercial trainer it’s a little bit of the chicken-and-the-egg problem. Until Perl 6 is out there and people start using it a bit, they’re not going to want training for it. Until they think that it’s going to be a real useful tool for them, there’s no financial reason for them to take training, so it’s very hard for me to sell. I’m really only selling to very forward-looking organizations who want to get a head start because they’ve recognized that Perl 6 is going to be a useful tool to them, even though they’re not using it now.
I think for me too it’s going to be step by step. I just can’t write 15 classes in Perl 6 because I don’t know what kind of training people are going to want initially, and I need to service the market. It’s not good having 15 classes in Perl 6 that no one wants to take.
You’ve got a number of books about Perl 5. The same names can be applied to Perl 6. Are you going to do that?
They certainly could be. I can certainly see myself writing a book on object oriented Perl 6. And I can certainly see myself writing a book on Perl 6 best practices. But I can’t see myself writing the best practices book until I have 5 or 10 years experience of what people do wrong in the language. That’s where the best practices come from. Seeing the mistakes that people make and the consequences of those mistakes…and we don’t know what they are yet. To write Perl 6 best practices needs a lot of experience in the community, and a lot of feedback, and me teaching a lot of people and finding out what they don’t do right. The object oriented book, not so much, because Perl 6 object oriented model is already very very solid, very very advanced, and very very able to be written about.
The last thing I’d like to ask you is about the naming issue. We have Perl 5 and Perl 6; these are different languages, but people will still think that Perl 5 is something from the past. How can we solve that without introducing Perl 7?
This is an incredibly difficult question and it’s an incredibly difficult question because Larry has decided that the language is going to be called Perl 6 and “Rule 1” still applies. Whatever Larry says about Perl is correct. It’s not like there’s really an alternative here.
I have to say that this is one of the main areas on which Larry and I disagreed for pretty much the entire design process. I’ve always differed from him on it. I’ve always supported his decisions on it, but I think it’s pretty well known that I have long believed that calling it Perl 6 is not helping it…and is not helping Perl 5.
There area a couple of possible solutions that I see. One is we just live with it. We recognize that Python 3 hasn’t yet killed Python 2 and C++ certainly hasn’t killed C. So maybe it isn’t all that much of a problem. It’s more a problem of marketing and people understanding that these are not successor languages, but they are parallel. Well, Python 3 still believes it’s a successor language to Python 2, but that doesn’t seem to be working out in the real world yet.
The other approach that I see is you can’t obviously go to Perl 7. Perl 5 can’t skip over to Perl 7 or something like that because then we have kind of “dueling banjos” going on. But I rather liked the proposal that was put up a year or two ago that Perl 5 could go to an entirely different naming scheme: still calling it Perl but maybe using the year of release instead. I’d be really interested in using Perl 2015 if that’s what Perl 5.22 was called. I think there would be advantages to that, because we still have people who are using Perl 5.8. If the name of that had been Perl 2002 then using it toady would be like using Windows 97. It feels wrong. You want to be using Windows 2010 or Windows 2015 or something like that. In the same way, people might be more encouraged to keep their Perl 5 implementation a bit closer to current day because they don’t want to be seen running on Perl 2002. I saw that as a possible way around the problem. Sort of: divert Perl 5’s naming scheme to be something completely different from Perl 6, so there’s no conflict between them, no race for the numbers.
Ultimately, it’s Larry’s choice. I haven’t been able to convince Larry, he hasn’t been able to convince me, but he has good reasons for the choices that he’s made and he’s a really smart guy. It might be that having Perl 5 and Perl 6 will actually turn out to be an advantage in some way that most of the rest of the community doesn’t realize until we look back and say: “You know what? Larry was right again!”
One thought on “Interview with Damian Conway”