Episode 13: Interview with Damian Conway, designer of Perl 6 programming language

Damian Conway is a computer scientist, a member of the Perl community and the author of several books. He is perhaps best known for his contributions to CPAN and Perl 6 language design, and his Perl programming training courses as well.He has won the Larry Wall Award three times for CPAN contributions. He worked with Larry Wall on Perl6 design for more than a decade.

Pramod: Hello People, Welcome to MappingTheJourney. Today I have a very special guest joining me from Melbourne, Australia. Yes, today’s guest is Damian Conway. Let us speak to him about his technological journey through the years, experience designing language with Larry Wall and more about Perl 6. Damian, It’s a privilege have you on the show.

Damian: Thanks, Pramod. It’s great to be with you.

Pramod: Damian, tell us about your early life. When were you introduced to computers?

Damian: Well, that was back in the early 80s, when I was at university. I didn’t actually study computers in my secondary schooling at all. I think we had one computer in the school but was nearly impossible to get access to it. So it was really when I went to university and started my computer science degree that I started actually working with computers in any meaningful way.

Pramod: Okay, so your introduction to programming when did it happen?

Damian: Well that was 1983 and we learnt Pascal and we also learned very low-level kinds of things, assembler programming and so forth and then the following semester we started working in C, which again I guess is also very low level, but something that stayed with me a lot longer than Pascal did.

Pramod: Okay, awesome…! So, introduction to Perl, when was that?

Damian: That was quite a lot later, that was around 1996. So at that stage, I was a working academic at Monash University in Australia, and I was mainly working in human-computer interaction, on stuff to do with generated text and of course, Perl was a great fit for that. I needed some tool that was better than C or C++ at the time to be generating text and analyzing generated text and natural language and Perl was kind of the best tool available at the time so that was my introduction to it.

Pramod: Okay, so in between, As you said 1983, you started using computers. So just in between like what were you, what do you spend working on, were you with the academics?

Damian: Yes, I went through my undergraduate degree and in my postgraduate degree and about halfway through my post grad degree, I took a faculty position at Monash as well and so I was in part doing my PhD which was mainly done in C++ and I was also working after that on research projects which were in whatever happened to be the right tool for the job, which was C or C++ or sometimes other things.

Pramod: Okay, awesome…! So, I read your interview with, I don’t know with whom, but, on Vim, so your love affair with Vim tell us more about that?

Damian: Well, that started probably in my second year of undergraduate studies in 1994 and of course it wasn’t Vim, at that time, it was just VI. So I’ve been using VI since then, so you know, over 30 years and I was a relatively late comer to vim. I stuck with kind of the vanilla VI that was available on most platforms for a long time after vim was out and it was only at the urging of some good friends whose opinions I respected that I took a look at VIM and of course as soon as I saw how configurable and how scriptable vim was, that was another love affair here. I got into that very heavily as soon as I discovered that I could make Vim do what I wanted rather than having to do what Vim wanted.

Pramod: Okay that’s cool. I was reading about your CPAN contributions, that’s a huge contribution there. How did it get started?

Damian: Well that goes back to what we were talking about me doing research into natural language generation and understanding, so the very first module that I put on CPAN was just a Perl module that would take English nouns and verbs and inflect them correctly for number, so in English you’ve got the problem of if you have a cat, then you’ve got more than one of them you’ve got cats and a rat, rats and a bat, bats but the rule isn’t simple like adding s, if you have an ox then you have oxen and if you have a man, you have men and so I created a module which understood the rules of English and enabled you to take arbitrary nouns and verbs and get the correct inflection and the problem I was solving there was simply: I hate when you see something like “one error were found” and I wanted to know, no, in that case, it’s a singular and it should be “one error was found” and of course if you’re searching for something you don’t know what it is you’re searching for and if you want to say one oxen were found that’s just as wrong, so I created this kind of general tool for that.

And then I kind of went mad with this type of module for dealing with natural language in various ways. So I created another module that was able to wrap text in a smarter kind of way than you would normally get from most text wrapping algorithms. I went on and created a module that would convert Perl’s standard error messages into Haiku. I was strongly involved in that kind of research at the time and Perl was just great, for being able to grab texts and modify it and investigate it and understand it and that was really how I got started.

But then of course, the more I used to Perl, the more I realized that there were certain tools that were missing from Perl and the great thing about Perl is if the tool is missing, it’s very easy to write a module that adds the tool to the language. And so a lot of the modules that I’ve written subsequently that were investigations of new language features or new ways of solving problems, some of which have ended up being added to the core of Perl and some of which haven’t, but the great thing is they’re all in CPAN and people are able to use them if they want them.

Pramod: Yes, CPAN is awesome and glad that you had this problem and so many people benefited with, as you said the parsing and regex side of it and I asked Reddit, any interesting questions and one of the guy was like, what are your favourite software modules in CPAN? Like, do you have any favourites there?

Damian: Okay, well a couple of my own modules I’m very fond of because I find them very useful and maybe the most useful of those is a module called Regexp:: Debugger. And the idea of that is very simply if you have Perl regexes and they’re not doing what you expect, it can be really really hard to work out why, so I wrote basically a visual debugger that walks through the execution of the regex and the string that it’s trying to match and shows you what’s going on at each step, and this can be really helpful and the great thing is all you have to do is use the module and then any regex is that you execute from that point onwards, just get automatically thrown into this debugger. So you don’t actually have to modify your code very much to make this debugger useful in context, so I really like that. Of my own modules, it’s probably the most useful module that I have.

Recently, I released a module called the PPR and this is, in fact, another module that creates a regex, but it’s a regex that parses most if not all of the Perl language, so this is a tool that I’m hoping that a lot of other people will find useful, so that I can build tools for manipulating Perl code in a more useful kind of way.

For other people, I guess maybe the most useful module that I know of that other people have written is Tim Bunce’s Devel:: NYTProf, and this is a profiler for Perl and it’s just extraordinary. And, I mean, Tim Bunce is an extraordinary programmer, who gave us DBI, and really didn’t need to do anything more for the Perl community, but Devel::NYTProf is just a fantastically good code profiler, so if you’ve created your code and it’s not running as fast as you’d like, I grab this thing all the time and look for those slow points and then start optimizing.

But there are so many good modules on CPAN, for development you’ve got Moose and Mouse and Moo and that whole hierarchy, which are extraordinary. I mean, they took Perl from having one of the least able OO systems to having one of the most able OO systems. And there are all kinds of other things on there that I use all the time. The Inline family of modules: if I need to drop back into C or I need to drop into Java or anything else, these inline modules make that incredibly easy and you know it’s really hard to pick a favourite on CPAN because there’s just so much goodness there.

Pramod: Yeah, yes. And you know when we look back at programming languages during when Perl was there was PHP, Perl was the first language to have something like CPAN, where people could put their software modules and everybody could use it. That’s a great thing about Perl.

Damian: It is. It’s maybe Perl’s secret weapon. The fantastic thing is when you’re a Perl developer and someone gives you a new task, the first thing you do is not sit down and think how can I solve this? The first thing you do is go to the CPAN and see has someone else already solved this. And it’s very often you’ll find that’s the case or in fact, five different people have solved at five different ways. And that’s part of the joy of working in Perl, is that you can get jobs done really quickly because a lot of the time the jobs are already been done for you and really only require a little bit of infrastructure to glue it together or a little bit of tweaking. And of course all of CPAN is open-source, so if you like what they’ve done but you don’t quite like how they’ve done it, you’ve got a really good starting point for something that you want to create yourself. It’s a fantastic resource.

Pramod: Yes, definitely and my favourite is debug Regex. I just love that, I’ve been used so many times; I enjoy using…

Damian: Oh, I’m glad that you found it useful.

Pramod: So, between, as you already said you were involved with academics. I was just reading your bio and between 2001 and 2010, you were an associate professor at Monash, here in Australia. Is teaching something you enjoy?

Damian: I love teaching. I think teaching is what I enjoy more than anything else.

Pramod: Okay that’s, it’s awesome. Next uh, let’s move on to your recent times. You spent more than 10 years of working with Larry wall on the design of this new Perl 6 programming language and producing documents and presentations exploring Larry’s design decisions. How was it like what, tell us about the experience working with him and your personal experience building this language?

Damian: Well, boy it’s hard, to sum up, a life-changing 10-year experience in…. Well, yeah it was it was everything: it was enthralling to watch the man’s mind work. It taught me a huge amount, not just about programming language design, it taught me about programming. It taught me about how to deal with people. I mean we had 361 initial requests for changes to Perl and it taught me how to just deal with a deluge of input and to make sense of it. It was humbling to work with Larry, you know I’d like to think that I’m a pretty smart guy, when you’re working with someone who’s like, it feels like, orders of magnitude smarter than you, that’s a really good experience to have, to learn other ways of thinking and looking at problems. I think I probably learned more about what programming is and how to do it well in those 10 years then I did in the 10 years that I spent as an undergrad or a post-grad. It was an extraordinary experience and an extraordinary internship. I learned about design and the other thing, kind of, that was unexpected was that I felt that I learnt to be a better person, I learned to be a bit kinder and gentler and a little bit more sympathetic to other people’s needs, other people’s limitations, other people’s approaches, just to ideas that were very different and sometimes contradictory to my own. And all of that basically came from working with Larry, who’s just an extraordinary person.

Pramod: Yes, yeah you had the opportunity to work with him and yeah very well said and I’m sure you had an experience of a lifetime and this is again with respect to Perl 5 and 6, what makes it different from other languages? I think you have programmed in, as you said Pascal, C, C++ many languages. What makes it different?

Damian: Okay um so, I think there are probably two things that make Perl, the Perl languages, different from other languages that I’ve programmed in regularly or taught or something else. The first of those goes back to the philosophy and the design of Perl and that is that, unlike most other languages that you encounter, the Perl languages really aren’t designed according to a single abstraction or a single organizing principle. You know the famous Perl motto is “There’s more than one way to do it” and that’s applied even to the design of Perl. So Perl happily steals concepts and approaches and tools and syntax from just about anyone who has a good idea.

The complication of that is though that you can do that and end up with this Frankenstein language and Perl, I don’t think does that. The great skill that Larry has is in taking pieces from various different environments and languages and paradigms and putting them together in ways that actually interoperate.

But the goal here has always been what used to be called in the Perl community: “practical utility”, so it’s not about purity and it’s not about elegance and it’s not about minimalism. It’s not about a single theory of computation. It’s about getting your job done. It’s about getting the language out of your way, making it less difficult to use the language so that you can spend more of your time and more of your limited intellectual resources on solving the problem. So for me you know that really differentiates Perl from most other languages.

And then the second thing that I think differentiates Perl is if you go back even one step further: what is Perl for. Perl really isn’t primarily about building programs or systems or libraries, Perl was designed primarily as a way for, kind of building communities and Larry has said as much in public statements, that Perl was designed first and foremost to create a community around development around these languages and that for me is the thing that really sets the Perl languages apart.

Whenever I interact with the communities of other languages, they don’t have the same feel to me as the Perl community does. There isn’t the same warmth, there isn’t the same humour, there isn’t the same strength of the community. There’s not even the same willingness to help. For the last, I guess 20 years, I’ve more or less made my living by people in the Perl community inviting me to come in and teach them or talk to them or train them and helping me to do that and the community has been so welcoming, so affirming, so supportive, so encouraging not just to me, but to basically everyone who comes to the Perl community.

We have tremendous resources within Perl for beginners you know, if you’re a beginner in Perl, there are all kinds of online resources where you can interact with some of the best Perl programmers on the planet and ask them dumb questions and they will help you. They’ll help you understand how to do the thing that you want to do, they’ll help you understand better ways of doing that, they’ll help you understand better ways of thinking about that. And for me, that’s the defining characteristic of the Perl languages, that they’re surrounded by a group of extraordinarily able and extraordinarily kind people. And for me, that’s what makes Perl really special.

Pramod: That’s awesome. It’s a very awesome explanation. I’m sure I’ve spoken to many Perl people, they, they are really proud of what Perl does and everything, the community is awesome. I have experienced that myself. I recently went to a meet-up and one of the features that the Perl community is speaking about is grammar and actions of the Perl 6. What makes them worth bragging about, in what situations might a developer want to reach out for such a tool?

Damian: Ahh…yes, you know I think there are a lot of things to brag about in Perl 6 but certainly the grammar features are one of them and I mean Perl is always, kind of led the field in text parsing. It’s what I got into Perl because of, and Perl’s regular expressions have for a long time been pretty much the hallmark of regular expressions across all languages, and to the extent that a lot of other languages boast of having “Perl-compatible regular expressions”. And those regular expressions are tremendously powerful, but the reality is that Perl 5 regular expressions are not easy to use and a lot of people don’t use them well. And the reason for that is that their interface is just terrible.

The regular expression syntax has grown from a very simple syntax way back 30-40 years ago and every addition to it has made it more powerful but has also made it harder to use and so when we came to looking at that particular aspect of Perl when we were designing Perl 6, we decided that we really needed to go right back to the basics of what regular expressions were for and to think about well, if we were starting from scratch, how would we design the syntax of regular expressions now? Knowing what we know in hindsight, what would we do differently? And we really went back to the basics and scrubbed almost everything about regular expressions, created an entirely new syntax that was a lot more readable, a lot more powerful, and in many ways a lot more convenient, because it’s got new features that reflect what it is that people actually do with regexes in the 2010s.

But of course, it’s not “Perl-compatible” because the syntax is entirely different and then on top of that, we realized that we had maybe 95% of what we needed to have full grammar support. So differences between regexes and grammars: it’s kind of like the differences between a method and a class. A regex is like a method. It’s a series of instructions for matching a particular kind of stream.[yes] And a grammar is more or less the way that you collect instructions for various components of some language that you’re designing and make them interact with each other. So when you’re building a class, you would create little methods that solve particular aspects that the class or the objects of a class need to do. And some of those methods would call other methods to solve part of the problems for them and so on and so forth. And the same thing works in grammars. It’s almost exactly the same thing.

So if I want to design a way of interpreting a file of, let’s say XML or JSON or Perl code or anything that you like, then the way I want to do that is by having effectively a class that says “I know how to parse XML or JSON or whatever” and I call a method on that class and that method would call other methods and they would call other methods and so on and so forth, until the whole thing has been parsed. Now, a grammar in Perl 6 is exactly that. It’s a way of saying “ok here’s a regex that a very high-level abstraction for parsing (say) XML”. Then when you parse XML and then you say “ok, what I want to parse is an XML header and then an XML body”. And so you write that literally as the regex that says parse the header then parse the body. Then, of course, you have to tell your grammar how to do that and so you write another regular expression, which says “this is how you parse a header” and that might use components that are decomposed as well into simpler and simpler components.

And this has been available in many different languages for a long time, going way back to things like lex and yacc, but also things like Antler and various libraries in many different languages. The problem is that none of those libraries or tools is very well integrated into the language and that was the great strengths of Perl’s regexes: they’ve always been integrated right into the language. And the same thing is true for grammars in Perl 6: they’re integrated right into the language to the extent that for Perl 6 code itself, the compiler parses it using a Perl 6 grammar. So it’s really eating its own dog food there and the great thing about that, of course, is that given that we have a complete built-in grammar for Perl 6, it’s really easy to build tools in Perl 6 that manipulate Perl 6 code. You know: refactoring tools, code analysis tools, profilers, whatever you want to do…because it’s already effectively built into the language.

But the other thing is because these grammars act like classes, you can actually inherit from a grammar in Perl 6 and create a new grammar by adding in extra rules and regexes to it. What that means is that you can create a basic grammar and then create newly derived grammars, which allow you to deal with variations in syntax.

So a classic example of that is config files. Every config file basically consists of a series of lines which are “key = value”, except the config files which are “key: value” and a comment at the end and so on and so forth, so you get these related families of languages.

You could look at programming languages, there are like 50 different dialects of Lisp and they’re all slightly different, but if you write a Lisp grammar in Perl 6, then you can start writing derived grammars for each of your dialects, and what’s incredible is that we’re already building tools that allow you to interconvert these.

So the great thing about a grammar is because it describes an entire hierarchical language structure, once you have a data structure extracted from that grammar, which grammars do automatically, then you can reverse the grammar effectively and generate new code out of internal data structures, so you can parse the code in, or parse the data in, or parse the HTML in, or the JSON in, or the SQL in, modify it in your program, in the data structure, and then send the data structure back to the grammar and have it reconstruct the new syntax for that in whatever format you are using.

And the key to this is a mechanism that you mentioned earlier called “actions”. So in Perl 6, unlike many other grammar systems that have been available previously, we completely separate the idea of the definition of the language that you’re parsing–that’s the grammar–from what do you do when you’re parsing it. By default, the only thing that Perl does is build you a parse tree of it. But you might not want a parse tree, you might want some other kind of data structure or you might want to reformat the text and just emit it as text or something else. So in Perl you have this kind of plug-and-play system, where you can make one grammar that describes your language and then you can have any number of different sets of actions, each of which is represented by a class and each of those actions you can plug in to do something different with your grammar and that’s what we’re bragging about.

That’s what makes it incredibly powerful, you get this kind of plug-and-play object-oriented structure both in your grammars and in your actions and you can simply build tools that you want, once you have the grammar in place and of course, if later on, the language changes as most languages do at some point, you don’t have to go back and change the original grammar, you just derive a new grammar and now you have the original grammar which supports original versions of the language and the new grammar which supports new versions of the language and because the actions are all object oriented as well, when you have a new dialect of the language you just derive a new version of actions and they fit together again. It’s very cool and really powerful. So, as much as Perl 5 was the go-to language for text manipulation, Perl 6 just ups the ante by maybe an order of magnitude.

Pramod: Awesome…! That so, I can see, why you love teaching. It was, it was amazing like, I could always almost visualize what you’re saying. It was really good and definitely, I’ll go and give it a try, with the grammars and actions after listening to this. Yeah, all the developers and the Perl developers go, they give a shot with grammars and actions of Perl 6 and one of the Perl 6, foundation inspiration was Paul Graham article the hundred-year language, I read that and has Perl’s community made any progress with that ambition and yeah and if so how?

Damian: Yeah, yeah, that that’s a really interesting point. I know that Larry recently talked about that in an interview that he gave as well. And I guess one of the interesting things is, that I think my view on both the original article and the talk that it came from initially and Larry’s view on that is actually quite different. I think we have made some progress towards the goals that Paul Graham enumerated in that article, but I’m not sure that I actually believe that this article and his premise has really held up, since the early 2000s when he wrote that article.

I mean some of the things he got absolutely right: he talked a lot about language convergence and Perl 6 is a perfect example of that because we went out and stole from everybody. If we found good ideas in any other language we stole them, both at the syntax level but also at the semantic level.

But I think that some of the other aspects that he mentioned in that article don’t seem to be panning out the way he expected and I think that leads to a different conclusion. So, for example, he was talking about the enormous increase in power that we’ll see by the continuation of Moore’s Law and he was talking about computers in a hundred years that are trillions of times faster than what we have now and I don’t think that’s actually panned out. I think that we’re starting to see we’re getting towards the end of Moore’s Law and the only way that we were continuing to see real improvements in the performance of computers is in the thing that he was kind of underestimating in the original article, which is concurrency.

You know, the circuits are getting as small as they really can and the only way of actually increasing the performance of computers is more cores now. In Perl 6 we really have focused on that and Perl 6 was designed right from the get-go and even more so in the last four or five years, we focused on this. Providing a language where it’s going to be really easy to slide concurrency in, mostly under the hood. That’s what Paul got exactly right: you don’t want most programmers trying to write concurrent code. [Yes] Because most programmers are not good at it and it doesn’t matter whether they’re smart programmers or experienced programmers, concurrency is hard.[Yes] and without the right abstractions, it’s very hard and the thing that we spent a lot of time in Perl 6 was looking at what are the right abstractions? What are the cases of concurrency where the compiler can insert that concurrency without you having to do anything? And Perl has a lot of constructs, both for data concurrency and also for task-based concurrency, where you don’t even have to know that they’re concurrent. It’s just if the system that you’re on and the compiler that you’re using supports concurrency, they’ll be emitted as the concurrent code.

And more recently, Jonathan Worthington has been doing a huge amount of excellent work in looking at well, what are the right abstractions when you do need to do explicit concurrency and how can we make those abstractions robust and composable and reliable and efficient? So, in that sense, I think we are in the spirit of the hundred-year language, even though that wasn’t something that Paul emphasized.

I mean something that Paul did emphasize was the importance of functional programming[ Yes] and again Perl 6 we spent a lot of time making sure that Perl 6 was a good solid functional programming language and we’re seeing a lot of language convergence that Paul was talking about in that arena. A lot of languages now–even those that weren’t initially functional in any way shape or form–are introducing functional components and Perl 6, we certainly have done a lot of that. Perl 6 will never be purely functional. It will never be Haskell, but, it will be a good and reliable and efficient and powerful functional programming language. It already is.

I think the most profound issue about Paul’s talk and article is that he mentions briefly the rise of non-algorithmic programming and non von Neumann architecture, so things like neural nets and deep learning and quantum computation, but he doesn’t really focus on that and I think (and it’s only my opinion) but I think that is going to be where we’ll be in a hundred years time.

You know, a hundred years ago the state of the art was some craftsperson sitting in a small room building a mechanical computational tool and you turn the lever and gears and cranks work and you got out computations. Today it’s text-based, multi-paradigm, high-level abstract languages like Perl 6. But when you kind of draw a line from low-level mechanical devices to high-level languages and say that’s a hundred years, if I draw it to draw that line out another hundred years I’m not sure I can predict what that’s going to be.

I am not really sure that, in a hundred years time anyone is going to be using any programming language at all, except maybe the society for creative anachronism. I think you know, it’s possible that if anyone is, they won’t even be carbon-based. There will be silicon-based people who are coding in ways that carbon brains won’t even understand.

So I’m not sure that the long-term goal of a hundred-year language is actually 100-year language, but I do think that what Paul got right, is that it represents an inspiration for us to say: “Alright then, look at the paradigms that seem to work better, look at the features from other languages that seem to work really well in those languages…and steal”. And of course I feel good about that because you know the Perl design is all about stealing great ideas from other people and coming up with our own great ideas as well, but we’re very happy to steal.

Pramod: Okay, awesome…! Very well said and uh and Perl 6 on the right track with that explicit concurrency something which would, everybody would love to use it every day and also very well said about the hundred year language thing. I don’t think so, we’ll be programming in next hundred years.

Damian: Well I certainly won’t. You probably won’t either Pramod.

Pramod: Yeah, that’s awesome. I don’t know if you want to answer this, if you get to, if you got to choose what Perl 6 be called, Perl 6 or something completely different, given a choice to you.

Damian: Oh wow…! That’s opening a can of worms. Or possibly a can of snakes. Well, the bottom line is, Larry has decided and he is the benevolent dictator of Perl and so the decision’s made.

But I’m on record of saying, as saying that I’m not really very happy with the name Perl 6 for various sociological reasons. I think that calling it Perl 6 does no good to Perl 5 because Perl 6 kind of implies that Perl 5 has been superseded…which is definitely NOT the case. I think it harms Perl 6 too, because in a lot of people’s minds Perl is very much associated with Perl 5 and has all kinds of baggage associated with it, which I frankly think they’re thinking about how Perl was 25 years ago not how Perl is today, but the bottom line is, I think that that confusion doesn’t really help. It hasn’t helped the Python community to have Python 2 and Python 3. [Yes] Not even sure it’s helped the C community to have C and C++ and C sharp and these others.

So, I really wish that we had gone with a different name, to represent that, although this is in the Perl family, it really is a fresh start. So you know I suggested “Rakudo”, which is kind of a pun in Japanese. It means “paradise”, but it’s also kind of a contraction of “the way of the camel”. And that is, in fact, the name of the main implementation of Perl 6 but I kind of wish it was the name of the language, or if we’d gone with something else, I was thinking you know “Onyx” or “Zeta”, it’s gotta be something four-letter ideally, like “Perl” was. Someone recently suggested to me that we should be looking into the Game Of Thrones popularity nowadays and I went and looked it up and in High Valyrian, the word for “six” is “Byre” and that’s not bad either. You know, if Roku hadn’t stolen the name, we could have gone with “Roku” which is Japanese for “six”. I’m really really envious of Apple, you know. Their relatively new language is “Swift” and that is one fantastically good name for a language and I really wish that we’d stolen that first.

So yeah, I certainly would have been happier if it was called something else but ultimately, I think a language doesn’t stand or fall on its name or even on the associations with its name. I think it stands and falls on its feature set, on its availability, on its support, and I think Perl 6 is going to stand because of those things. Everyone I convince to actually try Perl 6 finds that they love it and are very impressed by it. The trick is getting them over the name.

Something that I did a couple of years back, I was giving a lecture at CERN in Geneva and I said “Well I really want to come and talk to about Perl 6” and they “Well that’s fine but if we put the name Perl in the title of the talk then I’m not going to get anyone to come along”, so I said “Fine. I’ll go and talk about this theoretical language and we called it Albus”, for all kinds of reasons and I talked about “Albus” for an hour and showed them all the features, they don’t know that what I’m showing them is Perl 6, so this is the language, all the tools, all the different ways in which you can use Perl 6, all the things that might be useful if you’re trying to find new subatomic particles or understand the universe. And then at the very end, I said: “Of course the language is not called Albus, it’s called Perl 6”.

So we got past it in that kind of way and I’ve done that a couple of times since, but the reality is that if the very name Perl 6 is going to stop you from exploring this amazing new language then nothing I can say and nothing I can do is going to encourage you to do so.

Pramod: Ok. Honestly, Perl is a language for geniuses, that’s what myself and, many programmers think. Yeah, definitely when you see Perl 6, it kind of creates that fear it’s it’s a tough language, it’s a hard language to understand. So that’s where kind of I asked this question with the Perl 6 would have been easier if it had named anything else?

Damian: Yeah, yeah. If we had called it “Simple” or “Easy” (that’s a four-letter word!) then it probably would have been that, and I can understand that some Perl 6 code that’s been written and including some code that I’ve written and yes: terrifying.

But I think the great thing about Perl 6, in particular, is that we try to make the learning curve of Perl 6 really gentle, so I think that if people get over that fear that it’s a language for geniuses (and it IS a language for geniuses…if you’re a genius you can use Perl 6), but it’s also a language for beginners and for amateurs and for hobbyists and for people who don’t want to have to deal with the complexities of language.

So I would claim that C is more a language for geniuses, because of it easier to write terrible terrible C code than it is to write terrible terrible Perl code.

So, you know, I can understand that and I spend a lot of my time teaching people Perl 6, in academic environments, in corporate environments, and I can see the nervousness and the uncertainty, but when I actually go through it and show it to them they say “Well, hang on a minute, this is really easy, this is much easier than whatever I am using now. Why did I think this was incredibly complicated?” And the reason is, that’s the name, that’s what people say, but I don’t think that’s the reality of it.

Pramod: Awesome…! I’ll definitely go and I will start using Perl 6, you have convinced me to go and give it a shot.

Damian Well, then that’s great.

Pramod: Yeah, on the serious note, do you think Perl 6 has taken off successfully?

Damian: I don’t know. It depends on how you measure it. You know if you measure it from when we started developing it then Perl 6 is 16 or 17 years old and clearly, it hasn’t taken over the world yet, so clearly it hasn’t made the best use of those two decades.

But if you look at it from the point of view of when we actually released the language, when we said “Okay, it’s now ready to use”, it’s less than two years old. I think for a two-year-old it’s doing it pretty well. I think it’s about where it should be. We’ve got a very solid core of developers on board now, who are really extraordinary people, you know, I think that’s where the genius of Perl 6 is. The people who are developing and implementing and maintaining and improving Perl 6 are without exception remarkably capable developers.

What we don’t have yet is anything that approaches the environment that CPAN gives Perl 5. People are developing a lot of modules and you see five new modules go up on GitHub or on CPAN now which now supports Perl 6 modules, pretty much every week and we’re also well into the phase of getting faster every week in our optimization. And it astonishes me that for the last 18 months or so pretty much every point release of Perl 6 has been measurably faster. So that’s kind of where we are: we don’t have too many end-users at the moment other than people like yourself who might be investigating and exploring and playing around with it.

Ok, you know, I actually think that’s not a bad thing. The people who are kind of early adopters of Perl 6 need to be really enthusiastic, to put up with the fact that not all of the ecosystem is in place yet and their feedback is helping us really debug some of these core issues and get the performance to where it needs to be. The other thing it’s doing is, that it’s meaning that we don’t get too many bad reviews. The last thing you want is for people to go in and say “Okay I’m gonna try Perl 6…well, it wasn’t as fast as Perl 5 or it wasn’t as convenient to use as Python for this task”. So I really don’t want a vast number of people coming into Perl 6.

The other thing that we’re just starting to see and that’s going to make a big difference is, we’re finally starting to see enough literature around Perl 6, to make it feasible for people to really start. So this time last year there were basically no books about Perl 6 now there are 6 and within a couple of months, there’ll be eight or ten. So one of the things people need is someone to take them through and say ok this is how you need to think in Perl 6, this is what’s different about Perl 6, either from Perl 5 who’s there Perl5 developers or from whatever else they’re using and that’s starting to be in place there.

So I’m really not unhappy about where Perl 6 is. I’d much rather that we penetrate the markets slowly, but we did so by good word-of-mouth and that we kind of find our niches because there are so many choices out there nowadays. There are so many languages that people can choose to use, there are so many environments and library systems and everything. The only way you can get a foothold now into that mindshare is if it’s penetrating by recommendation and by word-of-mouth and by people just finding, hey this is really a much better way of doing it. Unless you’re being backed by a billion dollar company you know. Unless Google or Microsoft or Apple is pushing your particular language…and Perl 6 doesn’t have any of that. Perl 6 was a completely volunteer-based, open-source movement. We have a couple of paid developers now. Larry was supported through a lot of the development as well, but we don’t have huge resources so we’re pushing our language by making it as good as we possibly can and that’s what we’re in the process of doing and I think that’s the right way of going about it. So I’m reasonably happy, sure it’d be great if Perl was the number one language, but it’s never gonna be that. That doesn’t matter.

Pramod: Yeah, that doesn’t really matter. So, if I’m a new programmer, just started programming. Tell us why should I learn Perl 6? 1 or 2, I know there are hundreds of things, but like one or two things to say, I should learn Perl 6.

Damian: Ok, then there are a couple of different levels of that. If you’re talking about why should you learn it in terms of features well, obviously what we talked about in terms of grammars, is a strong selling point.

The other thing about it in terms of features is we designed Perl 6 so that it would support whatever style of programming you’re used to and comfortable with and competent in. So if you’re a procedural programmer, Perl 6 lets you do that. If you’re a functional programmer Perl 6 let you do it. Object-oriented programmer? Concurrent programmer? Do you like declarative styles of programming? Perl 6 supports all of those.

And not in the kind of way that you sometimes see with multi-paradigm languages, where it’s really one paradigm and we bolted some other things on. We really tried to make it so that you could natively program functionally in Perl 6 or natively program in an object-oriented style or mix the two together without it feeling weird. So I think the thing is: if you come to Perl 6, you can keep programming in the style that you’re already programming which makes it very much easier to get started with it.

But the real reason to start learning Perl 6 is that we designed it with a couple of goals in mind and those goals are goals that you as a programmer should want. One, we designed it so it would be easy for you to get your job done, so you’d write less code. And “less code” is kind of important because writing the code is, maybe five to ten percent of the task. Maintaining the code forever is 90 percent of the task, and the less code you have, the less maintenance you have…and a lot of research indicates the fewer bugs you’ll have. We also designed it so that it would be easy to make it interoperate with other languages, so if you’ve already got libraries in JavaScript or in Python or in C or in anything else, we wanted to design Perl 6 so that it’d be really easy to hook those libraries together using Perl 6 as a kind of the substrate. So you could pull in something from JavaScript and something from C and run it all together in one program. And you can already do that in Perl 6.

So I think that’s a big selling point of it and of course the other thing that I already said was because we have some of the best developers and some of the best community spirit of any language and that kind of makes learning Perl 6, and using Perl 6, a lot less stressful and a lot more fun.

Pramod: Ok, very well said Damian. In what ways does the choice of a programming language influence the efficiency of a developer?

Damian: Oh…! I think it has a profound influence, maybe less so as you get to be a more experienced programmer, but initially at least the choice of programming language is going to determine how you think about the problem, so this is kind of Sapir-Whorf hypothesis for programming languages: that the language or languages that you know, and the paradigms that they support, and ways of solving problems that they support, will basically limit the way you can think of solving your problem. So you know nothing about functional programming, you will not be able to solve your problem in a functional style, even if a functional style is exactly the right way to solve your problem. [Okay] So the choice of programming language really influences that.

The other thing that influences the efficiency of programmers is how much you have to do yourself. Do you have to worry about memory management yourself? Do you have to worry about data structures yourself? Do you have to build all your own data structures or are the data structures either in libraries you can use or built into the language itself? And the more tools that you have built into the language itself, the less actual coding you’re going to have to do yourself. And probably the more efficient your code will be because languages which already have these tools built in, presumably those tools have been very well implemented by very smart people.

Yeah, I much prefer not to have to write my own stuff because it’s likely that anything I write is not going to be good, as good as something that someone else has written and has been tested by literally thousands of people using it within the language. So I think in those ways what you choose for your programming language really does influence, how efficient you can be in solving a problem.

Pramod: Okay, that’s awesome. It was a great explanation Damian, one last question what has been the most satisfying part of your technological journey? 25 or even 30 years I think 1983, you said 1980 started?

Damian: Oh wow..! Most satisfying part, I’m gonna give you a binary answer: there are two aspects to it.[Okay] From a technological point of view, the most satisfying thing for me is: I just love solving a problem and I love that moment when I discover a problem and think wow that interests me, that’s something I want to solve. And I love the moment days or weeks or months later when I finally work out how I could solve it. And then I love the moment even later when the test suite all turns green, so maybe I’ve solved it. I love that I get paid to do that and I love that I get paid to teach other people to do that. Maybe I love the teaching other people to do it even more than doing it myself, but that for me is, it’s not having a job [okay] because if I was independently wealthy, I’d probably be doing this anyway.

The other thing for me though, the single most satisfying thing about my technological career has been the non-technological aspects of it. To be coding with other people, to be teaching other people to code. That’s given me the opportunity to work with, just even to meet, some of the best and brightest and most interesting and most considerate and most generous people that I’ve ever known. The people that I’ve met in the Perl community, in other programming communities, the open-source community in general, the people that I meet when I go into companies to teach them, or when I’m giving open classes in these things, almost without exception are remarkable: kind, good, interesting people. And I learn so much from them and for me, that’s the by far the most satisfying part of it. You know, I’m not even an extrovert; I’m an introvert. But to me getting to interact with these extraordinary people has been by far the highlight of a long technological career.

Pramod: Okay, awesome…! Damian I totally enjoyed talking to you. You were a wonderful speaker. Thank you for making time and thanks for being on the show.

Damian: It’s been my absolute pleasure, Pramod.

Pramod: Thank you. Wow. That was fantastic speaking to Damian. He is such a wonderful speaker and made immense contributions to computer science. I’m sure people, you all had fun listening to him and also it was so very informative. Next episode I will be speaking to Matt Mullenweg, founder of WordPress and CEO of Automatic. Looking forward to speaking with him. Until then, You all have a great rest of the day. Bye. Take Care.