miyagawa: I'm here in Brussels, Belgium with the special guest on my show. Can you introduce yourself a bit?
rjbs: My name is Ricardo Signes. I'm the pumpking, the release manager for Perl 5.
miyagawa: It's great to have you on the show.
miyagawa: Is this the first time to be in Brussels, Belgium?
rjbs: Yeah, it's my first time at FOSDEM and my first time in Brussels.
miyagawa: How do you find it?
rjbs: I like it. I always find it really interesting when I come to Europe that all the cities have a unique character and I can come to one city and it really feels like it's different than the last place I left. It's always enjoyable.
miyagawa: And we're here for this conference called FOSDEM, Free software Open Source software Developer European Meeting?
miyagawa: It's pretty much like, I don't know, Open Bridge, Open Source Developers Conference but it's [in] pretty European style, I would say.
miyagawa: There's no registration required. You can buy beer at the cafeteria and you can even drink it inside the rooms for the talks.
miyagawa: Kind of interesting.
rjbs: It's very unusual. It is very much unlike a lot of other conferences I've gone to. And not just because of that. It's like I had a flash mob of hackers show up and we all bring beer and talks about software. It's great. I like it.
miyagawa: Yeah. So it's the first time for me as well. It's the second day right now, and yesterday you gave a talk about Perl 5, the next release of Perl 5.
rjbs: Yeah, so the next release is coming out in May. And I think it's the 4th release I've done the release of. It looks good and I'm pretty excited about it. I always enjoy getting to give a talk every year what's new and tell people the stuff I think is really really exciting. It's exciting for me, and then other people get excited about the features and it makes me feel even more excited. So it's a lot of fun.
miyagawa: Yeah. Can you briefly explain what the structure of perl 5… the development of the language is, and when you took over this maintenance stuff.
rjbs: Yeah, so I would start with a really brief history which is, after perl 5.8, which is like THE perl for a long time, it took years for perl 5.10 to come out. And after it came out, it has taken a long time for the next bug fix release to come out. And there was a lot of unhappiness about how long the release took, and there wasn't any criteria for done-ness.
Jesse Vincent, sort of spearheaded an attempt to fix this problem. The fix was, every month we have a new development release, and every year we have a stable release. And a lot of this was copied from Parrot, which is a project related to Perl 6. They were doing this monthly releases and it helped them in a lot of ways. I've got an early doing of these monthly releases, and from there, when Jesse retired I got suckered into doing the annual releases.
So every year, we release a new stable perl, that's supposed to be safe, you can install it, you can rely on it. Very few bugs. And occasionally we do a bug fix release, and it tends to be very small, because we're pretty good at getting out most of terrible bugs before the stable release.
But every month, there's a development release, that's got the newest features that don't really work yet, and have the optimizations that turn out to break stuff, so we're always breaking stuff and fixing it again, and we sort of slow down as we approach the annual release. That's the phase we are now, where the development has slowed down a lot,
we're just trying to get to the point where in May you can install it and feel good about it.
miyagawa: Yeah. So the stable release is the even number.
rjbs: Right. As far as the linux kernel convention goes.
miyagawa: Right, so the development version is the odd number. Right now we're at 5.21.something.
rjbs: 5.21.8. And 5.21.9 will come out in about 3 weeks.
miyagawa: And usually, 5.22 will be released on 22nd of May.
rjbs: Yeah, it's stupid. (laughs) I like it to… So what we really do is, around late April, we start saying this is our candidate for releasing. And little bugs trickle in, little things, and we fix those one by one. Once you've gone - it's usually about 2 weeks - with no problems, and we had enough smoke reports for statistical analysis to say we're good about it, then we'll call it a real release.
And it just so happened for the last past couple of years, we could keep getting on or close to the American style date matching the version. So 5.18 on 5/18, we couldn't make 5.20 on 5/20, I was bummed.
rjbs: This year I'm hoping we'll see 5.22 on 5/22, but if we can do it earlier, maybe we'll do that. If it's a little later I'm not … we're not gonna release earlier just to hit the date, for sure.
miyagawa: Yeah that's true. It will be interesting [to see] what happens with the Perl 5.32 then. Since there's no 32nd day in May.
rjbs: Yeah, right (laughs) Hopefully that will not be my problem anymore.
rjbs: I like doing the releases but that will be a little too many. (laughs)
miyagawa: OK. So the development release cycle [is that] you basically make a snapshot of whatever is in the trunk, master or blead. You explained in the yesterday's slides [about] the stability of development releases during this yearly cycle. Can you explain it a little bit?
rjbs: Yeah. Actually I will give to a little bit of history again. It was, there was a point, during the early time of this monthly releases, where we had a code freeze. So like a day or two before the monthly release, we say "OK, everybody hold off on committing." But people don't like code freezes, they want to keep pushing their work, and you don't want people to feel like they have to stop. And it's gotten to that point now that there is no code freeze for this, whoever is doing the release will branch, and do all the work and later on will merge it back in. It's been a big benefit to just keep things moving.
With these monthly releases, they start after a code freeze, because there's a big code freeze to get the stable out the door. No one is allowed to commit new features or backward incompatible changes for about two or three months, before the release. People start having ideas, and optimizations. You can put them in branches, but if it's in branches, you don't feel like it's committed, and they really want to get it in.
So as soon as 5.22.0 comes out, everyone's gonna start committing 5.23.0's crazy changes. They're gonna start committing all the stuff they've had sitting around. And this is what I was talking about yesterday, this idea that you'll see the stability of the main development branch go from very very good to awful.
rjbs: It will take about a month. The first release tend to do hours after the stable release. So 5.22.0 and 5.23.0 will probably be the same day. Or the same weekend. After that, people will start committing crazy stuff. And the craziness goes on for a while, and it then starts to slow down. People see what's broken and start fixing it.
Hopefully, after we hit peak crazy, sometime around October or November, we see people focusing on, looking at the reports from our testers. Perl development has a huge suite of automated testers who builds on all kinds of platforms, and all kind of options, integrate with CPAN as much as they can. And they focus on fixing everything.
miyagawa: Yeah, when you say "unstable", I don't think that means the actual code will break, because when you ship even the development release, it will pass all the tests, right?
rjbs: Yeah. We are very … We feel very strongly about having all of our tests always passing. The committers know that you're not allowed to push a code that doesn't pass its tests. As soon as you do, what happens is an email, there's an automated… there's a Jenkins install. And Jenkins is constantly building perl on a few platforms. We're constantly building on Windows now, which is, to me impressive.
rjbs: And if someone breaks the build, an email goes to the development list, and it says the build is [broken]. It doesn't say who broke the build, but we all know.
rjbs: And we get to fix it as quickly as possible. You don't want to be the person who broke the build. At any point, we can take a snapshot, and it will be stable. It will build. The only question is have we inadvertedly broken something on CPAN, because we can integrate all of Perl [tests] in about 5 minutes on a modern PC, some other platforms will be longer and takes hours or days. Building all CPAN takes days.
miyagawa: There's an interesting email that comes from Andreas, who is the maintainer of PAUSE. His email subject is BBC, it's an acronym for Blead[perl] Breaks CPAN, I think.
miyagawa: I think he's constantly running the blead against a bunch of CPAN modules on his box or something, and whenever he finds out the break[age], he bisects on the commits, and emails to perl5-porters list as well as maybe the author of the module in question.
rjbs: Andreas Koenig cannot be thanked enough for this work. The BBC reports, Bleadperl Breaks CPAN - people often think that he's running an entirely automated process, and he's just got a script that notices this, but what really happens is, he receives huge amount of reports, from his own testing and from testing of others. When he starts to see statistical variation in how things are building, he will go and read the test results personally, he will bisect carefully, and I think he does a lot of them by hand, and then he will file the report. He will file it either with us, with the perl 5 development, or with the module author, based on who is clearly at fault. Or with both.
And the amount of problems that it catches is amazing. He will subsequently go in and say, "Last month I reported that this commit broke something, I have found 7 more things independently broken by that" and we know with the higher degree of certainty whether we have fixed these problems because we all change perl, all the tests still pass and now we can go and test all the downstream bits that are broken. It's incredibly useful to have a stable release.
miyagawa: Yeah, his efforts have probably been understated.
miyagawa: You mentioned crazy things going to the development snapshot. What kind of crazy stuff, can we expect for the next release of perl?
rjbs: So the next release of perl… it's funny because when I was building my talk, and I want to talk about the things that are new in the 2015 version of perl, Perl 5.22. I started off by thinking, were there as many exciting things as we had last year? It's kind of true, last year we had subroutine signatures, which is amazing, which is on the TODO list for 20 years, and we added new kinds of dereferencing, really really big stuff.
But as I started going through, there were a lot of cool things this year, one of the things we talked about is the new double diamond operator, for safer iteration of file handles, which fixes a bug that probably no one knows they have. (laughs) Scary bug.
There's a new change that came into perl last night, after my talk. In Perl, we don't have a type system like many people do. We don't pick the type of data and operator knows what to do, but the operators apply the type TO the data, which is an interesting model and it works well. But we've had a long standing exception which is the bitwise operators, the single ampersand (&) and single pipe (|). They look at the type of the data, but Perl's data isn't well typed. They pick how to operate based on the type of the data, and it can lead to bizarre bugs.
In Perl 5.22, there's going to be a new feature that makes those operate always on numbers. And if you want them to operate as strings, there are three new operators, "|.", "&.", and "^." and now it assumes strings. So they act much like normal perl operators.
There's a lot of other cool stuff, but the things I think we're seeing in this release are smaller, somewhat more esoteric, but it's still a good release. I'm certainly gonna upgrade all my stuff to 5.22 as soon as possible.
miyagawa: You also mentioned that [there's] not just cool new features, but you're yanking out some of the legacy of perl 5 that nobody uses today.
rjbs: Right. And it's very dangerous to talk about what features nobody uses in Perl, you'll find out people use all kinds of crazy stuff.
miyagawa: That's why Andreas is testing against CPAN.
rjbs: That's why Andreas tests against everything. And there's often this idea that "Well I don't use this, no one should be using this, so we'll pull it out" but Perl 5 has strong commitment to backward compatibility, one of the strongest that I've seen in open source languages. And we really don't wanna break things. We will, and there are times we will say, this is a justifiable break, and we have to do it. We also want to know what we've broken not break it by accident.
As far as removing things go, when I took over running the show, we had a lot of features that have been deprecated for years. 15, 20 years, they've been marked as deprecated. And we don't want to leave things in that position. We want to say, "they're coming out" ‘cause we need to get rid of them, they cause problems. Or, "they are not." And if they should be coming out, they come out. Some features have been marked as discouraged, which just means, "we'd leave it there, but please don't use it." but we're getting to the bottom of the barrel of things to remove that have been marked that way for years, so I'm looking forward to exhausting the list and saying, "Perl has no more huge problems that we want to remove. Huge problems we've got to keep." (laughs)
miyagawa: What's the actual process of removing features? Do they get marked as deprecated and if you use it on some version of perl, you get a runtime warning and then in the next version it gets actually removed?
rjbs: Yeah. As with a lot of things like this, it wasn't always well standardized. Some things got marked as deprecated in the documentation, some things had optional warnings. As of I think perl 5.12, all the deprecation warnings were turned on by default, so even if you didn't turn on warnings, deprecation warnings would warn. It says "you're using the feature that we know we want to remove from Perl and you should probably stop."
The rule is roughly, we put a deprecation warning in, and it will be there for two years, and then we'll remove the feature. And we chose two years, so that downstream distributors, like Linux distributions specially, they don't always release in the same cycle as we do, so we want to make sure that everybody can see the warnings at least once, if they're regularly upgrading.
Occasionally we will pull things faster. If a feature we find is… if we brew feature that is extremely obscure, or we believe it to be basically entirely unused, we might pull it after one year. We've also said we might wait longer although I don't think we've done that yet on anything.
You've already mentioned it, but before Perl 5.12, the release process was really slow, and was probably relying on just a few people's entire voluntary time. Since Jesse took it over, it's almost guaranteed that new release will come out every year, so that I think… the developers will be much more motivated to get those features in. Because before that, you never know when the next major release of Perl is out.
miyagawa: Even the .1, 5.10.1 took like three years to come out.
rjbs: Yeah. So there was two things there. One was, it used to be that all the new code was added to "blead" the blead is short for "bleeding edge" (laughs) the dangerous branch of Perl. Things are added there, and then someone in charge of selectively cherry-picking them, back into the maintenance branch. That's a ton of work, and it was scary and dangerous, because you didn't know how safe it was, and you had to make sure it's safe. So there's a lot of work, picking the commits, resolving conflicts in the commits, and testing them to make sure it's gonna work, and the work was being done by the very small number of people. All the code then was in Perforce, so there's a very small number of committers. It was difficult.
And as you say, it also meant that if you wrote a commit to Perl, you didn't know when you could ever use that. It could be applied, they would say "it's a great feature, we applied it," and you wouldn't know when you could use it, unless you use the snapshot of perl which was crazy.
rjbs: I remember feeling really discouraged on behalf of someone else, we had a feature that was added early in 5.9, which would eventually become 5.10, when 5.10 was gonna come out, I was writing a series of articles teaching people about the new features, and I found one of these features was really not going to work. It was not a good feature, and we removed it. But it had been added years before, by someone who wrote the feature, they added it, and they went away, and they weren't there to help, fix or discuss the feature. It's unlikely that they ever thought it was gonna come out. We didn't want everyone to let that happen again.
So, getting the releases once a year, I think is really good for morale. Absolutely.
Also, some of the features are added to Perl, but not enabled by default. So these features are opt-in, and you have to explicitly declare that "I want to use this new feature, I know it might not be perfect and might be taken out in the future if it doesn't work as expected."
rjbs: Right, there's been two ways we've done that. One is the features that are experimental, and this is a little bit new. Again, we've had experimental features for years and years. But you couldn't always find out what was experimental, and you might be using the experimental feature and relying on it heavily. We, as the development team would say, "that's experimental you shouldn't rely on it," but you didn't know. And it wasn't fair because there's no way for you to know.
miyagawa: Yeah. (laughs)
rjbs: The rule now is that the experimental features issue warnings, and they tell you that "you're using the experimental feature, you shouldn't do that." You can turn the warning off but the way you turn it off, by putting the line on your code that says "I'm using the experimental whatever." So that you forfeited your right to complain. You said, "I know it's experimental, it might be yanked, changed or anything."
I'd like to get experimental features non-experimental as quickly as is reasonable. I'd like to know that the feature works though.
And the other thing we do is, some features are added, and we think they're done, but you still need to opt in, because they change the way the language works, and we want to be backward compatible as much as we can. Like I said, it's a very important value to Perl 5. So you have to say I'm turning on this feature… usually you just say, "I know that I'm using the version 5.20" and that turns on all the 5.20 features.
miyagawa: So there's a feature pragma, "use feature ‘say'" for example, and there's also "use experimental" for example for signatures. I think smart match was one of the interesting examples, which was added to perl as a default, standard feature was kind of demoted to experimental.
rjbs: Yeah. There was a little bit of totally understandable unhappiness, because there were few features that did not use to issue warnings, that were not really considered experimental, but they went in to Perl during 5.10, during this period when the development was very strange, and people were not testing these features the way we expect they might. Smart-match you mentioned. Smart-match changed its behavior radically between version 5.10 and 5.10.1. It was modeled after perl 6 feature which subsequently also changed its behavior radically. There are other features like this, lexical topic is one of them.
As you said, we downgraded it to experimental. We didn't want to just say, "rip it out," we want to fix it, but we don't believe these are features that we endorse that… certainly I don't endorse the feature, I don't think it's gonna make your program better, so we want to standardize. If these features were written today, they would've gone through the experimental process and they would've been fixed or removed, not released.
miyagawa: OK. I've got a couple of feedback from the listeners before the show, about the subroutine signatures.
miyagawa: Because that's one of the biggest and most exciting features for 5.20, I think.
miyagawa: We've waited for that about, I don't know, 10 years, 20 years? Is it still experimental for 22?
rjbs: Yeah. So subroutine signatures were added in 5.20, and they were marked as experimental, and after 5.20, Peter Martini who is one of the developers who worked on subroutine signatures said, "what's the rule for something to become not experimental?" and I said "Well I haven't thought that far ahead." (laughs) So we had to start describing what this policy would be.
And the policy now says something like this: a feature cannot leave experimental status unless it has been unchanged for 2 releases. So, you have to know that it's good, you have to really not want to change it.
If you changed it, now you have to live with the changed version for a while. In 5.22 subroutine signatures are still experimental. I'm not sure whether they have changed significantly enough that they're off the table for being not experimental in 5.24.
rjbs: We know there're some ways to change them, most importantly, is the error messages they give right now are not quite as good as it could be. And there's some optimizations, but that's not relevant to experimental status. But yes, as of 5.22, still experimental. But I'd love to get it stable as soon as we can.
miyagawa: Yeah, I think I saw Peter Martini's talk YAPC::NA last year, or maybe the year before, about the process of getting subroutine signatures into Perl core. And his… his… how do I describe, he is so … patient?
rjbs: Yeah that's the word I would use also. (laughs)
miyagawa: (laughs) [patient] about the process. I think Daisuke Maki presented the translated version of the talk in YAPC::Asia last year, and I put the links to these videos in the show notes. He basically had a greater idea of what signatures should be in Perl 5, but he tried to get that into core, without putting… like "perl
5 has to do this, do that, and do this for signatures and otherwise it's not perfect." He put that feature into corel in iterations, so that, even if the first version of signatures doesn't get this right, it's better than having nothing.
So that's my interpretation of the talk, and the current version of signatures is still experimental in Perl 5.20, and maybe so in 5.22.
But it's so much better than having nothing.
rjbs: Absolutely! Yeah, it's one of these cases where I think one of the reasons that signatures didn't go in sooner, once you had the language for long enough without signatures, people would say, there's no reason to add signatures unless they give you everything.
And there's a huge discussions about what everything you need out of signatures, they need to do types, they need to do inferences and coercions… it was huge amounts of stuff.
And Peter very rightly said, "what I have provided leaves room for adding those features later."
And I think people will find that signatures we have cover 95-99% of your needs.
And we might as well put those in, and if somebody wants to add stuff later, great.
But if they don't, we have something really good now.
Personally, I would like to see more in subroutine signatures, which is… so right now, we haven't explained what subroutine signature is.
You can basically say sub foo, and put the variable names, like sub foo($foo, $bar).
Like in every other language.
miyagawa: Yeah, exactly.
But I think right now, it doesn't give you an API to get the list, the. number of arguments of subroutine reference.
Or, you cannot type those variables.
Perl 5 doesn't have strong typing - those kind of things, I think, are missing in terms of Peter's original idea.
So, typing the variables is a fun one because if we add something like typing the variables we wanted to be pervasive throughout Perl where you can type anywhere.
I was really excited because Python has been doing work on gradual typing. And gradual typing is, it's obviously the kind of typing you can add to Perl 5. If you are going to do anything, it's going to be like that, and there was going to be a talk on that yesterday and it ended up dissolving, the talk didn't happen. It was a real bummer but I want to find out… I'm following that thread on the Python development, hopefully we can steal some ideas from them, we'll see.
So, typing… typing is a big, tough… and I'd like to see it.
I don't know if it's going to happen. But there's a lot of other stuff, we could definitely do signatures.
miyagawa: Yeah, typing isn't just useful for compile time optimization but also useful as a documentation.
miyagawa: Especially when it comes to the subroutine signatures, so you can just see the signature, by text.
It has more information about the arguments and return types and stuff.
rjbs: So, one of the reasons that I didn't say but Peter was so patient, is that the discussions about signatures in the list were… they were very long.
Some people complain that they were sort of being talked to death, but I think it is an important feature, and it did need a lot of discussion.
One of the most interesting questions was, "are subroutine signatures part of the subroutines name, or are they part of its body?" This led to a lot of really big decisions about how they would work. I think that when you think about them as a part of the name you have all the stuff that you are talking about, you want to look at the subroutine and know, not just what it's short name is, but what it's arguments are. If you can see these things, you can understand a lot more about how the code works without reading the body. The less code you have to read, the better your life is.
miyagawa: Yeah, I think this might be derailing a little bit, but Perl 5 has this completely deprecated feature called pseudo-hash. You can declare a class for example, Point, and Point has an attribute called x and y, you can declare that with a pseudo-hash [fields] pragma. You can even annotate a lexical variable, as my Point $point - that's a really nice syntax Perl already has, but used for a completely different implementation.
rjbs: Yeah, so, it is a really interesting feature, you'd see it very rarely, and when you see it you see it in, like a Perl 5.0 introductory… and you can also use this. No one uses it.
A few years ago, I was on an IRC channel, and I said, "wouldn't it be cool if you could use those for Moose types?"
And Vincent Pit, who has written a number of crazy, really cool CPAN modules, wrote something called Lexical::Types. In Lexical::Types, you can register Moose types, which are type constraints, to act like this.
So you could have a point, Point::3D. You could say, my Point::3D $p, and it would be checked at all appropriate times to make sure it was that type.
I don't think that implementation is going to become a standard Perl thing, but certainly that syntax exists. And it is the kind of thing we would want to use ubiquitously, use it everywhere, to do this pervasive type checking. That's an idea that excites me. I don't know when it will happen, if it will happen. But it would be great.
miyagawa: Right. When I looked at the signature and think about that pseudo-hash stuff, why these features can't be married together to get the right signature, or argument type checking, and stuff.
rjbs: Yeah… A lot of the problem is that the pseudo-hash stuff, you get that with fields.
Now, pseudo-hashes are gone.
There's no more pseudo-hashes, let's not even talk about those. (laughs) But the fields pragma, lets you associate particular hash entries with your class, and it makes a lot of assumptions about what you are even using it for. It has to be a class, it has to be a class implemented on top of hash refs, it has to be implemented with fields.pm, it really limits what you are going to do, and that's contrary to how people want to write their Perl.
We need to break those rules, if we want to make something like that successful. I don't know who's going to do it.
miyagawa: Yeah, okay.
We are at FOSDEM right now, as we mentioned before. We saw the talk by Larry Wall this afternoon, about… well the abstract of the talk was mentioning Perl 6, but he didn't really talk about Perl a lot (laughs) What did you think about it?
rjbs: I always enjoy Larry's talks.
Simon Cozens tweeted, he said, "I love that Larry Wall always pretends he's going to give you a talk about Perl, but actually gives you a talk about life."
miyagawa: Yeah. (laughs)
rjbs: And Larry was talking about, so the theme of his talk was relating, he was making an analogy between the Hobbit and the Lord of the Rings, and Perl 5 and Perl 6. It was interesting, and I enjoyed it, I think that a lot of people have had unfounded ideas about Perl 6. Based on the fact that it's been in development for a long time.
I think the most interesting thing he said was, "15 years isn't a long time to wait, once you finished waiting." (laughs)
Once it's released, you don't have to wait anymore! You've got it!
And you can forget about the time waiting. And he said, he almost promised, that we are getting the 6.0 this year, and I'm looking forward to that. I've played a little bit with it, and it's always interesting and fun to play around with Perl 6. I want to see what happens with it.
miyagawa: Yeah. Absolutely. So, he basically mentioned that the beta will be available by Larry Wall's birthday in September, and the production release, or whatever, 6.0, will be done by Christmas.
rjbs: By Christmas, as promised!
miyagawa: As promised. Always, he mentions Christmas, but didn't mention which year.
rjbs: That's right.
miyagawa: But this time, [he] mentions this year. Any other thing we missed talking about…?
rjbs: No, I'm out of ideas, of course I haven't had a bunch of sleep here in Brussels, so…
miyagawa: Are you leaving tomorrow?
rjbs: I'm leaving tomorrow, probably, I'm leaving my hotel before dawn, so hopefully I'd get some sleep tonight, and hopefully the East Coast will not be snowed in.
Otherwise I'd just be landing in Iceland…
miyagawa: I think it's kind of unusual for you to give a talk about Perl 5 in January-February.
Yeah. That's one of the things I got to say, usually I give the talk after it's out. Well, it's funny, I say, I know everything I'm going to say is true, but we had a bug reported recently, that you couldn't… this is such a bizarre feature, we had a lexical subroutines, you could say my sub, and I said, the great use for this is using them in a sort routine, because you have to use a subroutine name, but turns out, you couldn't use them as sort routines, it hadn't been implemented. And I was showing it in my examples.
But usually what I'd say is true. This year, we will have to… I'd love to find out in May. But it was fun, it made for some challenges deciding what I thought was going to stick around.
miyagawa: There were interesting things to come in 5.22, you have explained some of those in the slides, but I don't think they are useful to talk about on the audio. So a lot of the things related to, like "those sigils are gone", "you can change this to the backslash"…
rjbs: Perl's hard to talk about! (laughs)
miyagawa: Exactly! (laughs)
rjbs: All those squibbly symbols…
miyagawa: (laughs) Yeah, so far, I think we've been doing great.
miyagawa: So are you going to give the updated version of the talk in the coming YAPCs?
I'm really looking forward to the updated versions of the talk, because for one thing I can put in bitwise operators, which are still secret. (laughs) I can be a little more certain once in and out, and I'm really hoping I can start talking about more things that we will see in 5.24. I always like to put a little bit of that, because of course when I give the talk in the summer conferences, the new Perl has been out for 2 months, then we've had some things starting to land.
One thing I didn't talk about yesterday was, I'm expecting Perl 5.22 to be a lot faster. Or, at least noticeably faster for a lot of people. There are a number of really interesting optimizations, one of which really speeds up deep de-referencing. So if you have a deep reference structure, it can convert all of the de-references into a single operator.
A single-op code called multi-deref. And, there are a number of other optimizations sort of sitting on the sidelines, that we knew we couldn't put in yet. And I'd love to see those land in Perl 5.24. So, Perl getting faster and faster, as well as better and better. I'd love to talk about that.
miyagawa: Yeah. I think one of those optimizations was sponsored by booking, as well as The Perl Foundation's grant.
There are few people who write fixes and patches for Perl, sponsored by the Perl foundation who gets donations from individuals and from companies who use Perl. Tony Cook, and Dave Mitchell do a lot of this work, and Dave Mitchell has been focusing a lot of time on optimizations, partly on his work from the Perl foundation and he's also been working on… doing some of his work for Booking. The benefits have been great. Before that there was Nicholas Clark, who has done a great great work from this. All of the money that has gone to the Perl foundation to fund that, I think has really paid off. It has been getting this great work, and a kind of work that volunteers are less likely to do, because it's hard, and it's gross, and it's dealing with nasty nasty pieces of code.
So yeah, Dave Mitchell has done a lot of work to optimize things, I recently saw some of his proposals for new changes, and I think they are really exciting. I look forward to seeing things get faster. (laughs)
miyagawa: Yeah. Nobody will complain about Perl getting faster.
rjbs: That's right!
miyagawa: Especially when they get that for free.
That's right, exactly.
miyagawa: So if the listeners are interested in contributing to the development of Perl 5, what are the options to get involved?
rjbs: I always tell people that they should join, and read at least some of the Perl5-porter's mailing list. I think the website… and I'd feel really embarrassed if I'm wrong, I think the website you would want to go to is dev.perl.org.
miyagawa: I'll put the link in the show notes.
The Perl5-porter's mailing list is occasionally high volume, it's no Linux Kernel mailing list. It's certainly no Linux Kernel mailing list for attitude either, it's generally pretty friendly. We have rules about being friendly - you must be friendly.
That's how I started working on the Perl Core, I joined the list and I just read what people were talking about. It made me a better Perl programmer, and it helped me learn how to contribute to the list. It can be a lot of mail - but you don't have to read all of it.
People often ask, what are some simple bugs that they can work on. And we do have a few collected tickets of bugs that need work, that don't require you already know how Perl's implemented. Those bugs are often tough, though. If it were easy it'd be done already. So often the best thing to do, I think, is to join the list and pay attention to what's going on, and contribute that way. And when you see little problems come up, be the first person that submit the patch, and you'll see how welcome you are in the community, absolutely.
miyagawa: And even if you don't know C… I myself don't know C a lot, not enough to patch Perl's source code, you can submit a documentation patch or write a unit test, that addresses the problem that you have with your code.
rjbs: Yeah. I tell people, I don't code in C. I do a very very small amount of C, I have maybe two patches in the core, that are basically C patches. And here I am, administrating the project. You can do a lot, you can do a lot to help the project without learning C, and even if you know C, you don't have to learn the bizarre macro-laid full of C, that we used to write Perl.
Yeah, documentation patches, tests, fixes to the many many pieces of pure Perl code that are put to core -
they are all great contributions.
miyagawa: Yeah, it's great. I'll put the links to p5p, and all the documentation websites in the show notes.
miyagawa: Okay, I think that's it.
It's great to have you on the show, we really enjoyed the conversation.
rjbs: Thank you!
It's good to be here.