Rebuild A Podcast by Tatsuhiko Miyagawa. Talking about Tech, Software Development and Gadgets.

miyagawa: So, I'm in Brussels, Belgium. Before this interview, I interviewed Ricardo Signes, the current Perl 5 maintainer. It was an interesting talk, and now we have Larry Wall, creator of Perl, among other things.

Larry: Hello. (laughs)

miyagawa: So, is this the first FOSDEM for you?

Larry: Yes. I am a FOSDEM virgin.

miyagawa: (laughs) Yeah, same for me. How do you find the conference and the city?

Larry: That's a..., well, the city is quite interesting. I've been in Belgium before but never managed to get into Brussels. The only thing that bothers me about the city is, I grew up in cities where all the streets go North/South and East/West, so everything is at an angle here.

miyagawa: Yeah.

Larry: FOSDEM, it's amazing how well it works for being so self-organized. They are not... mostly not professionals running this, it's almost all volunteers, and yet it runs quite smoothly.

miyagawa: There's no even registration, and most of the dev rooms, Perl dev rooms, Ruby dev rooms, Python rooms, all self-organized by the volunteers in the community.

So this afternoon, this is the... we're recording this on Sunday, February 1st in Europe time, and this afternoon, you gave, kind of like a keynote style talk in this conference.

Larry: Yes, so, I couldn't make it to OSCON this year, so I was kind of thinking this is a State of the Onion speech that had been delayed by 6 months, but it was also very exciting because we recently come to the conclusion that we can probably get an official - for some definition of official - production ready version of Perl 6 out by the end of this year.

So our old joke about, Perl 6 will be up by Christmas, we won't say just which one it is, we are speculating heavily that this is going to be the actual Christmas that it comes out. So that's exciting news, and we are certainly hoping that we can all follow through on that.

miyagawa: Yah. So the announcement you made was, by September this year, your birthday, you'll get the public beta preview for Perl 6, and by Christmas this year, you'll get the first production release of Perl 6.

Larry: Yeah. So, there are a few speculative things that we need to experimentally put in, early in the year, then toward the end of the year we need to settle things down and make sure all the bugs are fixed, that we've sorted out all the tests, the ones we actually want to support for 6.0 and the ones we want to put off for the future.

So it's been a long time coming, that we could see that everything was converging, on a solution, we just didn't know how fast it was converging, now it looks like we can have something that will be pretty generally useful. It probably won't run quite as fast as Perl 5 on everything, there are some things that will run faster than Perl 5, but in other areas it is still lagging, but that'll come with time.

miyagawa: Yeah. I think the original announcement for Perl 6 was in 2000.

Larry: Yes, in July of 2000.

miyagawa: So it's been 15 years of...

Larry: Almost! Yes. Yeah, in my talk today, I compared that with the amount of time that Tolkien took to write his sequel to the Hobbit, which you know, is the Lord of the Rings, and that one came out okay even though it took so long. So, we are hoping that we can kind of follow in Tolkien's footsteps.

miyagawa: So you mentioned that Perl 6 is obviously a second-system syndrome, but this time it's a different mistake you are making.

Larry: (laughs) Well, we had a long list of mistakes that we knew about Perl 5, so we weren't going to make those ones again. We knew that we were changing intentionally from the start. We said, "If we are going to break things, let's break everything that needs to be broken." which is, how you get second-system syndrome. And we even knew that. But we chose it intentionally because the problem with second-system syndrome, if you try to do it in a company, you have a burn rate, you are paying employees, and overhead, and you got to get customers, or pretty soon the revenue stream dries up.

With a volunteer organization, that is just working on it as they can, you can stretch it out, and because of that, I mean that's actually what Tolkien did, too, he just stretched out his writing until it was done. That's actually how you do second-system syndrome right, so our slogan is "second-system syndrome done right."

As long as you eventually come to a solution, then hopefully that's a happy resolution of the problem.

miyagawa: Yeah. So when you look back this 15 years of development, what kind of mistakes do you think development has made? Can you talk a little about some of the examples or specifics?

Larry: Well, we probably separated the rolls a little too much at the beginning between language design and implementation. That's only partly my fault. When we started off they said, well, we need the language designer, because we can't agree on how to change the language, but we don't want you involved in the implementation, because we already saw how you program Perl 5, and we didn't like it.

miyagawa: (laughs)

Larry: So, I stayed far enough away from the implementation that I probably did not have sufficient oversight of some of the ways things were going wrong in the early stages. And the project itself, you know, I'm not a good manager, I'm much better at language design than managing people. I'm so bad at delegating, that I even delegate the delegating to other people.

And unfortunately, some of the early programming, in it we ended up with Parrot that was too large for pretty much anyone to understand completely, and understand how to refactor it. So, while that was kind of going along slowly, we had several other implementations attempted. First was Pugs, that was very useful to try to implement Perl 6 in a very strict language, that would force us to decide what the exact semantics of various parts would be.

But even more than that, that's when we started getting a test suite, Pugs was, Audrey said, "you give me test and I'll code." That worked quite well for a while, but eventually that project kind of fell apart, but we did learn a lot from that. Later on down, we had another project called Niezha which was an implementation Perl 6 on top of .NET, CLR, and Mono, and that actually was quite speedy, and a good proof of concept that we could put Perl 6 on other VMs. Some of the decisions we made about garbage collection, and those turned out to be good decisions. Unfortunately, that project we also learned that, assuming how you structure the internals don't really work right.

So it turned out that Rakudo on top of Parrot, about the same time they were deciding that they wanted to have Perl 6 on many different VMs as backends. And so, they chose to create an intermediate portability layer, which they called NQP, which is Not Quite Perl, so it's a subset of Perl 6 which is more easily portable and has simpler semantics, but it's quite a bit harder to program in. And it is quite unforgiving if you make mistakes. But is is fairly easy to port, so they first officially ported to the JVM, and at the same time they were kind of secretly working on a new VM called MoarVM, and now JVM and MoarVM implementations are fairly comparable. The MoarVM implementation is, it starts up very fast, compared to the JVM anyway, and runs quite fast and has type specialization and just in time optimizations and inlining that same sort of things that are happening in JVM as well, that cause the program to optimize itself over time, and that seems to work out quite well for a language such as Perl 6, especially with the gradual typing that we have at the high level.

miyagawa: Does the JVM backend have a special name for it?

Larry: It's just a Rakudo JVM, or Rakudo Moar, or Rakudo parrot.

So far, we've been also maintaining the parrot backend, but there are some historical code in there that's a lot of conditional compilations that are not very pretty. So that's why I told the implementers, that this year, if they needed to they could sort of neglect that backend in order to get MoarVM out by the end of the year. And somebody may well pick that up and carry forward that work if someone is interested in doing that.

The JVM is more likely to track closely, because I think we have a little more interest in people wanting to run on top of the JVM.

miyagawa: Yeah, for sure. So when you say, Perl 6.0 will release by Christmas, is that going to be Rakudo with MoarVM backend?

Larry: That will be Rakudo with MoarVM backend, yes.

12:00

miyagawa: Okay. So, this conference, yesterday Curtis Ovid, he gave a talk about Perl 6, and you gave a keynote at the big auditorium. Looks like the attention gets to... a lot of attraction here. Do you feel about that?

Larry: It's definitely, we are getting more interest now, as we get closer to something that is useful and stable, and more well understood. More people are getting excited about it, and we are having, in Ovid's session yesterday there was standing room only, we were actually cheating on the "room full" rules there.

miyagawa: (laughs)

Larry: And in fact it was already full when I had to come in late, and I saw the "room full" sign, I said, "Hmm, I'd better go in anyway..." (laughs) It was a good thing because I had to answer some questions, too.

miyagawa: Yeah.

Larry: But yeah, we are quite gratified to see the interest. I'm glad that Curtis was able to, sort of, present the simple end of Perl 6 because those of us who have been working with it for so long are excited about showing off the really fancy stuff.

(laughs)

Larry: And, it's a good thing to have someone worrying about the learnability end of it, too.

miyagawa: So he explained Perl 6 for "regular" people, if you say.

Larry: Yeah. He was trying to stick to the stuff that doesn't look scary.

miyagawa: (laughs) Yeah, in other Perl conferences like YAPC::NA, you show more hands-on coding for Perl 6 with like a demo. Today, you did only a couple of those.

Larry: Yeah, I did a couple of those as more or less just a teaser, the talk was more about the philosophy and the history of the whole thing, to indicate some of the inspiration in my thinking and what brought me to here, but also how the Perl community acts a lot like the companions in the Lord of the Rings, and supports each other along the way and they all take turns goofing up and taking the lead, and helping each other out. It seems like a good metaphor to talk about.

Yeah, I just gave a few teasers yesterday, it's not just the small end of the language that he was presenting, the easy end, but he did a really good job of showing how clean the semantics are of Perl 6, especially in numerics. Then a lot of thinking and talking about how to make things behave the way normal people expect. So if you add some fractions, it tries to do it exactly the way a person would expect, not the way someone who's gotten used to floating point numbers would expect.

miyagawa: So, you mentioned the role. Your role at the community is the language designer, what's the size of the Perl 6 community today, and what kind of people are leading this effort and implementations?

15:55

Larry: Most of the activity is centered on the IRC channel, #perl6 on freenode, on any given day there is usually about 200 people attached to that channel, of course some of them are lurkers, some of them are bots.

(laughs)

Larry: But actual active developers is a fuzzy set, but on any given day we might have 10-15 people actually working on things in different areas. The various low level operations in the VMs or documentation, or tests, or debugging and experimenting with the higher level language. An interesting activity that happens almost everyday is that someone will get an error message and we will look at that and we will say, "it is LTA," which means Less Than Awesome. So, one of our many goals is to get rid of all the messages that are LTA, and replace them with awesome error messages. So we worry a lot about how things go wrong, not just about how things can go right.

miyagawa: I remember [that in] the early days of Perl 6 development, there was the RFC process and Damian Conway was writing down a bunch of articles about how things should behave. Are those RFCs still the design principle[s]?

Larry: Well, they are not so much the design principles as the indicators of pain. We looked at those RFCs, I expected about 20 of them. We got 361. It actually set me back on my heels for 6 months, while I just thrashed mentally. Until I kind of figured out an order to just start thinking about them. but it was obvious after reading through them all that there was no way that these taken together would present a coherent design. Each of these RFCs, they sort of looked at a problem in isolation, with blinders on, and said "well, let's just fix this one thing, and here's how we would do it." So, if we'd done all those things it would have just been a complete hodgepodge, a mess.

So we had to back off and basically throw out all solutions they proposed, and say, "what are the underlying pain points, what's the cry for help here" and then start to unify... start looking for unifications of principles that were behind why people were hurting.

Once we did that, we started seeing themes like, "well, a lot of these RFCs were a direct results of having a sloppy type system." So, we started thinking, what sort of a type system should we have, and should we allow programmers to continue to think sloppily about the programs? And we actually decided, yeah, there are lots of ways in which it is fine for programmers, especially a new programmer to be sloppy in thinking. What's not fine is if the computer is sloppy in thinking about it.

So with Perl 6, the user might not really quite be aware whether a particular variable contains a number or a string, and it will interconvert it for him. But the computer very much knows what the actual declared type of it is. That makes it much clearer what the semantics are.

And there were other unifying themes that we detected on many different levels, so just over time we found designs that fixed a lot of the surface issues that people were complaining about. And often fixed them on a deeper level than they had suggested fixing them.

miyagawa: So, is the type system... is that called gradual typing, you mentioned?

Larry: Yes, we call it gradual typing, basically you can write code that is type-less as you would write most Perl 5 code, or lots of other dynamic languages. But as you add type declarations, these type declarations actually take effect at compile time, and inform the compiler, as to the intended uses and this has several beneficial effects.

Probably the least important is what people call strong typing. We can't enforce certainly some of the type constraints at compile time, but most of them are enforced at runtime. The seconde eason for doing it is that it gives the compiler much more information to optimize with. So if you know the types that can or cannot be stored in a particular variable, or a structure, then you can optimize the representations of that and the processing of it.

But really what it turned out to be the most important thing was, we have a system called multiple dispatch, sometimes called multi-method dispatch, but we also have multiple dispatch on subroutines and functions as well. If you write your... a set of functions that all have the same name but differ in the type signatures of their parameters, then it will automatically dispatch to the correct subroutine or method. This can fill in for... what in an older languages you'd use switch structures for, but it's much more extensible because you just add more multi-methods or multi-functions as you go along, and it all just works together in an appropriate way.

So that's really the most important reason for having the stricter types underlined, is that we can very clearly decide whether we should dispatch to the one with arguments that are numeric, or the one with arguments that are a strings, or whatever other object types you are dealing with.

23:13

miyagawa: So the language knows the clear semantics of the types.

Larry: Yes. In Perl 5, you could actually change the type of a scalar by observing it. And we decided this was a bad idea.

(Laughs)

Larry: It's okay if a scalar sort of object... when you coerce it to something else if it caches the coercion so it doesn't have to do it again, that's just an optimization. But if it then actually takes a value that you really ought to be considered immutable, and mutates it, then you are starting to get into a trouble. Especially if you are relying on the type of it before and suddenly the type changes, then you are just horsed.

miyagawa: Yeah.

miyagawa: So, when you ship 6.0, probably by the end of Christmas this year, what's coming after that?

Larry: Well, maybe we'll take a long vacation...

(laughs)

Larry: I suspect that, we will have to negotiate that when we get there, it may become obvious after we've sorted out the various tests into pre-6.0 and post-6.0, what the next thing to work on is. But that will be difficult to predict.

miyagawa: Yeah. I guess you mentioned in your talk that nobody should expect the perfect implementation with dot-0 [release] anyway.

Larry: Yeah. Well, we'll do our best.

(laughs)

miyagawa: Okay. I mean, I don't think you can predict things like this, but you think the versioning strategy for Perl 6 in general would be, 6.0 is the major release, 6.1 is the next major release...?

Larry: I think that's the general feeling that the major numbers would indicate breaking changes or some incompatibilities. But then the last one, lower numbers would indicate bug fix releases.

We do have a plan for being able to emulate different versions even if... if you download a later version of the code but you declare that you are using an earlier version, it can try to emulate the previous semantics to the extent that there aren't security holes. There is other strategies for keeping the thing forward and backward compatible.

miyagawa: But when you say 6.0, it's the Perl6 6.0, it's not Rakudo 6.0 or anything like that.

Larry: No. Rakudo actually uses version numbers that are date based.

miyagawa: Right.

Larry: So, let's see, 2015-01 for, well, wait, today is the first, so the -02. And then the sub-sequence number within that, and probably, actually a git hash.

miyagawa: Right. It's really canonical versioning, and it doesn't have any meaning.

Larry: Well, we are moving more toward a world where, versions are kind of arbitrary, I mean, I'd like to know the ordering of them, but what's really important is maintaining identity. And once you put a module or an implementation of something out there, it should really be considered an immutable object, out there in the world, and if two people download the same thing and they have the same crypto-hash, then you should be able to rely on the fact that these are in fact the same thing. So that's part of our strategy.

We also... another part of the strategy for future proofing is that we want to, if you have different dependencies on the same module, but on different versions of the same module, to the extent that we can we want to allow people to run two different versions of the modules simultaneously. That's hard if they have a shared resource, like a database handle. But that usually means that should be factored out into yet another dependency. So, if module A and module B both use module C, but one wants version 1.2 and one wants version 1.3, as long as we keep them semantically close enough to each other and without having them interact with each other, then you can actually just load both of those in, and as long as the computer is not confused again, about the identity of who is using what, then we have to be able to keep that straight. And that's another strategy for not breaking every time someone downloads a new module.

miyagawa: Right. Does that mean you can load the same... two different versions of the same module, in a same process?

Larry: That's the hope.

miyagawa: Okay. I guess that would affect how CPAN works for Perl 6.

Larry: Yeah, some CPAN modules will, obviously, if they aren't written well enough, may... or if they are relying on a low level threading primitives in Perl 5 that don't work so well, then obviously going to have trouble under it when called from Perl 6. But, the modules that are fairly well behaved, we can probably actually use the concurrency model of Perl 6 to coordinate these various Perl 5 modules, in a way that Perl 5 itself could not.

29:45

miyagawa: Okay. Well, you probably mentioned, but I think the original, I mean I'm not sure if it's original, but there was this idea about running 5 and 6 in the same process and call the modules each other.

Larry: We can do that now, already. Inline::Perl5 module allows us to pull in modules of Perl 5 into Perl 6, and even derive Perl 6 classes from Perl 5 classes, and to have call-back interfaces, if necessary. There's still some gotchas in there, and it's not going to be as efficient as if the modules were implemented in Perl 6, to begin with. But for problems where you can partition the work nicely into, this is the things that Perl 5 is good at, and these are the things that Perl 6 is good at, and there's not a lot of cross-communication then, those sorts of problems would be quite easily solved with this sort of a situation.

miyagawa: That's exactly like when you write a code in C and call it from Perl 5 using XS. In the same way, you can call Perl 5 code from 6.

Larry: Uh-huh. At one point, the author of these modules was calling into Inline::Perl5 and that was calling into Inline::Python.

(laughs)

Larry: Which was... fun. (laughs) Actually, now I think he's probably got Inline::Python directly for Perl 6. I could be wrong about that.

miyagawa: Is that a thing?

Larry: I think it's a thing. (laughs)

Larry: I mean, Python has some great libraries, and we'd love to steal them.

miyagawa: [Does] the JVM backend for Rakudo access to the existing Java libraries?

Larry: Yes, it does. It's even gotten easier lately, because it will map the overloadings that Java allows and maps into multiple dispatch in Perl 6. So, when we first had it, you had to put the Java subsignatures they gave us types as part of the name. Now you don't have to do that anymore, so you can just call it by the simple name.

miyagawa: Yeah. Yesterday, I went to this Ruby dev room [for a] talk about JRuby, and they talked about many JVM optimizations they got for free. So that even the same JRuby code can run faster just by updating JVM and things like that.

Larry: Yeah, we certainly noticed, when we first put the Rakudo onto the JVM, for certain problems it would really speed up as it learned about the program. And MoarVM of course is much younger, not as mature, but it has the same strategies for hotspot kind of optimizations and inlining, and type specialization and de-optimization if necessary, but speculative optimizations that usually are right, is doing a pretty decent job with those.

The JIT doesn't produce spectacularly good code yet, there's a lot of room for improvement in the actual machine code it produces, and there's various other places where we can do a lot of much better optimization. List processing is not very efficient right now and we think we know how to fix that. The native types, especially arrays of native types, if you take that together with the various parallel processing primitives that we make available, should make for some spectacular, really fast number crunching capabilities at some point. It should be quite easy to map hyper operators into your GPU, for instance.

miyagawa: That's exciting. So I think, is this the first official announcement about this coming Perl 6?

Larry: It's the first time we've actually named a date. We've always had the old joke, it will be ready by Christmas, we just won't say which one.

miyagawa: Right.

Larry: And, this is the first time we have actually identified a particular Christmas we are aiming for. And you know, we may yet miss, we are of course human, and sometimes things go wrong. But we've been tracking the convergence of the implementations with the design, over a number of years, and that was, really all we were concerned about was that did converge. As long as it's convergent, then eventually we'll get there, and it just looks now like the convergence is close to ****.

miyagawa: Cool. So I guess we hope to see more of the progress around this year, at the other conferences, YAPC::NA. Are you going to OSCON this year?

Larry: Planning to. I didn't make it last year, because my retina fell apart in my right eye, and after surgery, they put a bubble into my eye, and I was not allowed to travel above 2000 ft altitude. You can't get out of California, without going over 2000 ft altitude, unless you take a boat. There weren't any boats going where I wanted to go, so I was kind of stuck there.

So I didn't get to OSCON this last year, for the first time. I was kind of treating this talk today, as sort of a delayed State of the Onion talk.

miyagawa: Right. Which you usually give at the OSCON.

Larry: Yeah, I do. So I plan to be at OSCON, and plan to get to various of the YAPCs as well. And these various other conferences, too.

miyagawa: Right. Maybe the one in Tokyo, as well?

Larry: We've been invited to there already, and are planning to go, yes.

miyagawa: That's great. In this conference I don't see... usually when I see you at OSCON, we also see your sons, Lewis and Aron.

Larry: You know, my kids are all like grown-up, and mostly moved out of the house. Lewis got through college, and he's still... he came back home for a while, but... my daughters are both married, have kids, and my older son is now in his second post-doctorate. This is Aron, he is in the second post-doctorate for institute for advanced studies at Princeton. That's like where Einstein was, and he is doing black hole thermodynamics, like Steven Hawking stuff. So, we got some scary kids, actually.

(laughs)

Larry: The girls are both spectacularly good artists. Lewis is my programmer, and he's... I had to get at least one hacker out of a bunch of them. We are proud of our kids. Geneva actually considers Perl to be her sister, because she was born at about the same time Perl was.

miyagawa: (laughs) That's great!

miyagawa: This is my personal question, what's your daily... what does your regular day look like?

Larry: Well, when I'm in the Pacific time zone, I usually get up and make myself some coffee, I'm not good very much before that, and then, I have to spend some time just back-logging everything that happened overnight, on IRC, because the development goes on around the clock. And a lot of that development happens in Europe, while I'm asleep. So I spend [some] amount of time in a various... sometimes it takes all day to get through that backlog, depending on how complicated it is, and what issues arose. Sometimes I can get through it quickly, and work on something else.

So, it is difficult to say that I follow an exact schedule on that. Often I end up finishing the backlog about the time to eat lunch. And then, I'm old enough that once I've eaten lunch I pretty much have to take a geezer nap. I get up from that, and sometimes putter around the house to fix things, sometimes go back to backlogging, and interacting with people who have questions, or need direction, or who want to tell me how I am thinking about things wrong.

We are all on the channel, spend a fair amount of time helping out the newcomers, also. And, various evening things... depending.

39:38

miyagawa: Your IRC handle is "TimToady".

Larry: Yeah, it's not spelled like the acronym, for There Is More Than One Way To Do It, but that's the derivation of it. It was actually a terrible pun, when I came up with it originally, because my boss at that time, I was working at O'Reily and Associates, the head of that is Tim O'Reilly, so I was "Toady-ing" up to Tim, also the past of my [***] name was Tim, so a sort of a double-pun.

miyagawa: Ooooh.

Larry: Now I'm not... now I don't have either of those, but the nickname stuck. It's fun though, because sometimes on IRC channels, someone new will come on, they don't actually know that that's my nick. I enjoy sort of going incognito a little bit because I get an honest view of what people are actually thinking. As soon as they know it's really me, then they clam up.

So the other folks on the channel know that I like to play that game sometimes, and kind of play along with it. So I'll start talking about Larry. They'll come in and start talking about Larry and as a third person I will too.

(laughs)

miyagawa: That will be interesting to see if you join the channel. I will join the channel just for that.

Larry: Well, if they'd listened to this podcast, then you'd already spoiled it.

miyagawa: I already revealed the identity. Okay. So, listener question: what's your favorite Japanese food? (laughs)

Larry: Ahhhhh. My favorite Japanese food... I like sukiyaki. Unfortunately I can't eat ramen, because it has eggs in it. Oh, actually, if you count by how often I eat it, Yoshinoya.

miyagawa: (laughs) okay. Your favorite Japanese food [is] gyu-don. Beef bowl.

Larry: Yeah, beef bowl, I usually get the combo bowl but we've been to Japan a number of times, and eaten in the Yoshinoyas there. I was disappointed the last time I went to try to eat it, Yoshinoya in the fish market, and I discovered that they are closing the fish market.

miyagawa: Yeah?

Larry: They are moving it somewhere else, so they won't be the original Yoshinoya [in fish market] anymore.

M I think it will happen next year, or later this year.

Larry: It was already... they had pretty much had it closed down when we were there the last time. At least certainly they weren't letting tourists in any more.

miyagawa: That's true.

42:45

miyagawa: Alright. So if the listener wants to contribute to this Perl 6 development and stuff like that, what's the available options? What would you recommend listeners to do?

Larry: Well, of course it depends on your interest, some people love to do documentation, and other people hate it. It is actually quite valuable if you are a newcomer to find out where the hurdles are, the difficult-to-understand spots, and if you fix those spots in the documentation, or in how the culture works, then it's easier for the next person coming. So some people like to pioneer that sort of thing.

Other people love to write tests, those are probably the mean people, they like to break things.

(laughs)

miyagawa: [They] write the test that fails.

Larry: Yeah.

miyagawa: But that's...

Larry: It's an important thing. Your best tester is sometimes, for some products, your best tester is a 2 year old, because they'll push the buttons in the order that nobody expected. I don't know that we have any 2 year old testers yet, but maybe we need some.

And of course there's various levels of hacking on the actual code, and various cultural support kind of roles that people have taken on. If you want to learn Perl 6 really good, and you actually want to program in it, then I'd say, find something you want to do, that you'd think will work nicely in Perl 6. Something that will actually motivate you. Perl has always been about supporting people, with their external motivations. If you want to write poetry in a computer language, then Perl tends to support that. If you want to write code that is very short and unreadable, we call it "code golf" we support that. Though, Perl 6 doesn't support as well as Perl 5, we are not really optimizing for code golf.

(laughs)

Larry: But some people will enjoy doing that.

Other people like going out to some websites where they put up lots of different tasks and problems, and solve them in a particular language, and it's a lot of fun to do that in Perl. Myself, I've put a lot of solutions on a site called RosettaCode, and this is a great site if you are into comparing different languages. If you know other languages and want to know what the corresponding code in Perl or Perl 6 would look like, it's a great place to study those things, and I've had a great amount of fun over the last few years, adding hundreds of entries there. And it's also been very useful because as I did that, I discovered places where the design wasn't really quite good enough.

miyagawa: So by posting entries to RosettaCode, you find some points and places where it could be improved in Perl 6, and get that feedback.

Larry: Yes. We've improved a lot of things based on difficulties I've had on RosettaCode, some of the language designer, they sort of looked larger to me. These problems... I'm sure other people would have other problems and they'd think those would have to be fixed first. Sometimes the trivial things I notice get fixed, and then the important things don't get fixed.

(laughs)

Larry: Hopefully it all balances out in the end.

miyagawa: I think the Perl's motto of "there's more than one way to do it" still applies to Perl 6?

Larry: It certainly applies technically, and also culturally. We are very interested in helping other people on many different levels, and I have an awful a lot of fun. Sometimes, we have some things that are deeper than fun, that you might call joy. Sometimes things that are not so fun have to be done, and yet what we would tell people is that have the appropriate amount of fun. To debug a problem in the garbage collectors is not fun at all, but, so we say, "have the appropriate amount of fun," meaning negative amount of fun.

(laughs)

Larry: But, we recognize that that's how one person sort of suffers on behalf of someone else, vicarious suffering is the illogical term. Or, more humorously, what we say is that we torture the implementers on behalf of the users. Implementers are actually kind of proud of the fact that they are tortured on behalf of the users.

(laughs)

Larry: I think that's some sort of fun, so we go with it, and it works.

miyagawa: Yeah, great. I'm really looking forward to the actual release of Perl 6 by Christmas, and looking forward to playing with it! Thank you very much.

Larry: Have the appropriate amount of fun!

(laughs)

miyagawa: So that was Larry Wall. Thank you very much.

-- Transcribed by May Horimoto