The Changelog: Software Development, Open Source - All things Perl (Interview)

Episode Date: December 3, 2014

Adam and Jerod talk with Curtis "Ovid" Poe about how he got started with Perl, what Perl is really good at, why he doesn't expect everyone to love Perl, why Perl doesn't get no respect, the difference between Perl 5 and Perl 6, and why the Perl community doesn't like marketing.

Welcome back, everyone. This is The Change Log, and I'm your host, Adam Stachowiak. This is episode 133. Today, Jared and I talked to Curtis Poe about all things Pearl. A great conversation. You're going to love it. This show is sponsored by CodeShip, Rackspace, and StatusPage.io. We'll tell you a bit more about Rackspace and StatusPage.io later in the show.

But our friends at CodeShip are all about continuous integration and delivery as a service. You can release more frequently, get faster feedback, and build the product your users need. A simple push-to-repo runs your automated tests and configured deployments. From the simple deployments of Roku to complex deployment pipelines for large infrastructures, they can all be set up with ease. They even integrate with GitHub or Bitbucket. You can get started today with their free plan. The setup takes just three minutes.

Make sure you use the code THECHANGELOGPODCAST to get a 20% discount for three months on any plane you choose. Head to codeship.io slash thechangelog and tell them The Changelog sent you. And now, on to the show. Hey, everybody. We're back, and today we're joined by Curtis Ovid. Ovid Poe, actually. He's got a cool middle name there. It's not his real middle name. Maybe at some point, Curtis, you can mention how you got that name.

It's here for your internet handle, right? Yes, it is. I'm here. Jared's here. We're all here with Curtis, and we're going to talk about Pearl. So we're excited. What's Ovid? Ovid. A long time ago, when I switched from mainframe development and getting into Perl, I decided to sign up for the website called Perlmunks.

And I happen to tremendously enjoy poetry. And when I had to pick a username, my two top favorite poets were an 19th century Scottish poet named John Davidson or the Roman poet Ovid. And John Davidson sounded like a very stupid username. So I picked the username Ovid and it just stuck with me for the years. I like Ovid. I wish I had that name. I could be a BA with Ovid.

Oh, his poetry is phenomenal. Highly recommend it, particularly translations by Peter Green. So that's obviously language dependent there. Highly recommend it, particularly translations by Peter Green. email we ship uh we have a featured section in there for pings we get on the ping repo drop an issue in there just like robert norris did or robin on github did uh to suggest us to talk to curtis and talk about pearl and kind of bring we've never actually had a pearl specific show on this uh on the podcast so we're excited about that but uh every week we feature how many repos we feature j Jared, in weekly? Three. Three.

Okay, so we feature three repos in our weekly email via ping. So if you've got some awesome repos out there you need some extra traction on, drop them in there. They might show up on the podcast. They might show up in the email. They might show up on the blog. You just never know. We might even tweet it out. So with that said, let's drop into to this conversation with curtis curtis you know jared jared and i you know jared back in college you did some pearl work i own a few pearls um we probably have a pretty diverse listenership to this uh to this podcast

that is going to be really adept to programming but maybe not that big of a fan to pearl so what do you say to those people who are not huge fans of Pearl? I actually don't say anything to them. I understand that not everyone is going to be able to get into every language. And Pearl, during the late 1990s, early 2000s, was rightfully called the duct tape of the internet. And as the market has grown and there was such a low barrier to entry, we have a lot of competitors come in. And for any healthy market, of course, it's going to shrink our market share. And so for a lot of people who didn't care for the Perl syntax, they were happy to turn away from it. So it's kind of sad because it's a fabulous language

and we shouldn't let the punctuation characters in there turn people away from it. But nonetheless, you know, people have their opinions. And just as I understand that, I also like other diverse languages. I enjoy Python. I enjoy Ruby. I like Prologue. I think it's fascinating. But I understand not everyone likes everything. Lisp, I think is phenomenal language, but I don't care to program it just because I just find it so frustrating and ugly when I play around with it. No offense to Lisp programmers out there. So I don't really stress about it much. I understand that it's not everyone's cup of tea. So you've been doing Perl a long time.

You've written a book on Perl. You have a consulting company that consults on Perl. What is it about the language that you fell in love with? It was an accident. In, I think it was 1999, I was a mainframe programmer and I was working, I was mostly doing COBOL development. And one of COBOL's worst strengths is, worst abilities is dealing with freeform text.

And that's pretty much all the web is incidentally, which is why COBOL, even though it's tried to, it's never broken out of the web. And I was working on a program to convert NT CSV files into the mainframe fixed width format that COBOL is really comfortable with. And it was about 150 lines of code and there was a bug. And someone didn't understand something called the unstring function, something we would call split in many modern languages, which splits a string on a character. And I fixed it. I got it down to, I think like 80 lines of code. And this Unix sysadmin kept telling me, you got to check out Perl. So I checked it out and I got this 80 line COBOL function down to about 10 lines of Perl. And that was with error checking. And it

was actually fairly readable. And I was thinking, my goodness, what the heck am I doing? And when he eventually left to form his own company, he said, come along. I know you can do this. And I haven't looked back. Though the ironic thing is I enjoy a lot of other programming languages. I program in C, Assembler, variants of BASIC, Java, Ruby, Python. But I joined Perl right at the time of the dot-com collapse. So I stuck around with Perl for so long that after the economy rebounded, I found myself in a situation where people would see so much Perl on my CV, either they didn't want to offer me a position or they would offer me a junior programmer salary.

So I wound up sticking with Perl, and I've been specializing in it for about 15 years now. That seems fitting that the thing that brought you to Perl seems to be its best trait, which is, and what it was designed for, right? Isn't it all about text extraction and manipulation? That's initially what was going on. Larry Wall, the creator of Perl, he originally released it in 1987. And he was trying to handle a lot of problems that SED and AUC and other tools were supposed to be doing. But he wanted to do it in one tool to make it very easy. I believe for reporting for NASA, as I recall. And then he eventually released Perl open source to the community, Perl 1 in 87. And it just took off from there. It was just so phenomenally easy to hack in Perl. I mean, today, I often find myself writing quick bash scripts. And as soon as they start to get complicated, I say, okay, forget about this. I switch over to Perl, because it makes things so easy. But at the same time, I also specialize in extremely large-scale

websites, database-driven, that use Perl almost exclusively as the back end. So it's everything from the really tall, really small blue things that we have to the very large-scale websites. Some of the largest e-commerce platforms in the world are driven with Perl. And it's just amazing how easy it is to shift back and forth. Like in Java, I'm not going to use Java to hack out a small utility for gluing things together. It just wouldn't make any sense. At the same time, Tickle might be great for a lot of smaller tools,

but a lot of people complain it doesn't scale as well. Though, again, no offense to the Tickle community. So it just really fills a sweet spot for me of being able to solve virtually all of what I tend to do on a daily basis. One of the biggest Pearl advocates and fans that I know on the podcast scene is John Syracusa, who writes Pearl professionally to this day and loves the language. And one of the things that he says that's interesting, and maybe you can tell me if this resonates with you, is that Perl is really kind of a formalization of the Unix way

and kind of taking those ideas of those small tools and those command line tools and wrapping them in kind of a nicer language. Does that resonate with you? Yes, it does. And I'm actually going to go back to COBOL for just a moment, if you don't mind. There's a reason for that. So one of the things fascinating about COBOL, what made COBOL so powerful and why it stuck around for so long

is because COBOL is not very good. It's not very powerful. It's hard to write big systems in COBOL. So what you do is you write a small COBOL utility, which maybe reads some records from an ISAM database and stores them in a file. But you have JCL, job controlling, which kind of, it's tough to describe. It doesn't really have a good analogy today, but JCL would have different steps. So you call a step, which would read that COBOL program, which would read the data, save it to a file. You call another step, which would sort that file. And then the next step might load another program, which would read that file, add some more data in, save it. And then you call another one, which would take that saved file, pass it on to another system. Basically, it was a Unix pipeline.

And that's part of what made COBOL so incredibly powerful because it wasn't powerful. So people built a lot of small decoupled tools and kind of piped them together with JCL. So that worked out very well for me when I was transitioning into Perl initially and getting used to the Unix model because it was used to the way my mind already worked. Build small tools, pipe them together. So that's part of the reason why, yes, I write a lot of Bash. I write a lot of small bash utilities to get stuff done. But anytime it starts to become painful in bash, and anyone who's done enough bash scripting knows what I mean, I just switch to Perl and I can do the same thing. And it winds up being, it's not quite as simple as bash, but once you get to the stuff that bash is a little bit weaker on, or maybe my bash knowledge isn't as good in, Perl just makes it so easy to glue all these different tools together, to shell out to some

other program, fetch its results, you know, fork off multiple processes, run a whole bunch of stuff, aggregate them together and push it out there. It's just, it's lovely. It's simple. And, you know, from scaling down to that small scale, the really tiny things you do up to the big, large scale systems, it just, it's always amazed me how seamlessly it tends to do that. Let's talk about some of the large scale systems you speak of. Do you know any off the top of your head that are like, you know, well-known sites that people may not realize are actually powered by Perl on the back end? It depends on what other people would think of it as a well-known site. So I live in Europe, and one of the well-known sites over here is Booking.com. Until the IPO of Alibaba, they were the third largest e-commerce site in the world

after Amazon and eBay. I mean, they're huge. They're not as well-known in the United States, but basically they're an online hotel reservation system. And they're massive. And yet almost the entire back is written in Perl. And I remember when I was working for them, one of my first days there, I was walking by this guy and he was hacking on some Java and I was surprised. And I said, what are you doing Java program? What do we do with Java here? And he said, well, we don't, we're taking all of our Java programs and we're

converting them to Perl just because it's easier to work with. Which I found rather ironic because sometimes you hear about it going the other way around. People are converting Perl to some other language. And here they're converting from some other language into Perl. And it's something very common for them, but they just found Perl so easy to work with. So that's possibly the biggest company I know of. I work for the BBC also, world's largest broadcaster. They had 26,000 people when I was there. And I was working on the central metadata

repository, which basically that was information about what their schedules were, what programs were on telly. And I found it rather ironic that me, an American who didn't watch TV, was telling the British people what TV they were going to watch. And all of that was managed through their PIP system, all written entirely in Perl. And just many, many companies like that. CrowdTilt, now known as Tilt.com, which is a popular crowdsourcing system, is written entirely in Perl. There's actually an MMORPG called Lacuna Expanse, which has been written in Perl. Lots of large-scale systems.

Some are well-known, some are less well-known. So there's a lot of it out there. Yes. Man, it's been around a long time. There's a lot of it out there. It has a lot of virtues. What is it about it? It seems like Perl's behind the scenes.

Is it just bad marketing or is it just communities that, you know, don't necessarily overlap? You know, we keep our thumb on open source and, you know, we have to go out of our way to find Pearl open source, even though it has been from the very beginning. So what is it about Pearl, the community? Is it just small or is it just not vocal? Why it's not better known in the greater open source community? At one time it was. Obviously late 1990s, early 2000s, as I mentioned, Perl was known as the duct tape of the internet because it was.

Virtually everything that you wanted to know on the web. If it wasn't written directly in Perl, Perl was supporting behind the scenes. And that's still often surprisingly true today. I work for a number of different companies. They call me in for all sorts of consulting things, and I'm finding Perl all over the place. But I think part of what happened was back around 2000, 2001,

there was kind of a malaise in the Pearl community. Internally, they were still trying to work out some differences. Some folks were frustrated. And there was a famous incident when John Orwatt threw a mug at the wall, shattered it, and said, we've got to do something different. And then the Pearl Six project was born. And there was a misunderstanding from the beginning. It was decided that Pearl Six would be the successor to Perl, but then it was quickly realized that it couldn't be the successor to Perl. And instead, it would be a sister language, just as you have C Sharp as a sister language to Java. C++ is kind of a sister language to Perl. Perl 6 is a sister language to Perl 5. And a lot of people simply see Pearl 5 and they don't realize that we have major releases

every year or so. New features, powerful features being introduced all the time, but people just keep seeing Pearl 6 and they're not aware that development is still continuing on Pearl 6, that Pearl 5 is still progressing at a tremendous pace. And internally, I actually was doing a lot of work with marketing with Pearl and I discovered a tremendous amount of hostility from the Pearl community for marketing itself. They were just happy to sit back and get stuff done. And that kind of caused a problem. So people outside think that Pearl 6 is a successor and therefore Pearl 5 isn't going anywhere. Well, that's absolutely not true. We're on Perl 5.20 right now, Perl 5.22. It's going to be out fairly soon.

New features being added all the time, powerful features, and it's a great language, but we don't do a great job of talking about it outside of the community. It sounds like some misinformation there sort of stouts you a little bit because you obviously want to progress, but you don't want to stop the progression and be like that Perl 5 is not going anywhere. Can you talk a bit about beyond that, the health aspects, I guess, of 5 versus 6 or where that's, you know, what's some of the biggest issues are around this 5 versus 6 transition?

Well, they're entirely separate languages. That needs to be understood, first of all. As I mentioned, they're sister languages, like C Sharp or Java, C++ to C, to Lisp. Yes. There is some work being done to make Perl 5 run inside of Perl 6, but it needs to be understood that they're not the same language. So because we haven't done a great job of communicating that outside and because a lot of people just see that Perl 5 was released, that was actually back in 1994 that Perl 5 was released.

That was 20 years ago. So people aren't aware that Perl 5.20 is not the same language as Perl 5. Perl 5 code will generally run with a lot of warnings in 5.20, but 5.20 and the supporting libraries that are available for it, such as Moose, probably the most advanced object-oriented system you're going to find in any dynamic language today, and possibly more advanced than most static languages, I would say.

Fabulous tool. I miss that when I program in anything else. There are such wonderful things available for Perl 5, but people outside the community aren't aware of that. I would like to see the Perl community. We've done a great job over the past few years of internally getting our act together, healing, pushing things forward after that malaise

of people internally not understanding the Perl 5, Perl 6 split. But it would be great if we can communicate that better outside, because if people outside of Perl aren't aware of how powerful it is, the powerful web frameworks, ORMs, and other tools that we have, we drive a lot of what's called the BioPerl movement, so there's a lot of biological research being done with Perl. If people outside aren't aware of that, it's harder for them to make the decision to choose that. Let's pause the show for just a minute. Give a shout out to a sponsor. Rackspace has been

helping us out. They love open source. We love open source. We've been working with Rackspace for the past year. And one of the things they keep telling me is how much they love open source. And that's why they keep sponsoring the show and making sure that you know how much they care about it. And that's also why they're giving you and everyone else who wants it $50 a month in credit for 12 months. That's right, $50 a month in credit for 12 months to explore their open cloud. All you got to do is create a Developer Plus account to get started. Go to the changelog.com slash rackspace to get started you get dev to dev support so if you got complex questions you can talk directly

to their developers about their sdks and their apis they have various services included like monitoring dns auto scaling orchestration private networking the list goes on there is no usage limits you can use user services as much as you, and you're only billed for usage beyond $50 a month. Again, they're giving away $50 a month in credit for 12 months. Go to the changelog.com slash Rackspace to get started. And now back to the show. Yeah, something we have in our notes here too, and I'm going to quote this back to you because this is what you said. You said the Perl community, and you've said this too here in the show just not as succinctly as this

you said the pearl community has been stunningly bad at marketing in this area meaning um you know this divide between pearl five and pearl six and just in general what pearls is going to do today and what it's doing today and jared i think that's something maybe we can even possibly help out with. Curtis, you mentioned in the bio information, different areas where Perl is doing some cool stuff. I think it's neat how the change-up can kind of step in and have Curtis on the show and talk to what probably is, we have a large Ruby audience, a large JavaScript audience, to some people who don't often look at Perl and say, oh, that's neat.

We should try that out. But maybe there's a space here where there's some interest to pick up. How great is the divide between the two as far as sister languages? Are they syntactically very similar? Do they have huge differences? Perl 6 was just a huge undertaking. Is it used in production? I'm just having tons of questions pour out of me here.

Ovid, pick any of those and just run with it because I've got so many questions now. If you were to look at, maybe an interesting example would be there are many people who criticize Perl. They're unhappy with it. People who don't know Perl, they look at it and they just see a bunch of sigils, punctuation characters all over the place. Many of these people could look at Perl and PHP and not tell you which is which. They're not going

to say anything about PHP. They might have different complaints about PHP, about how it's kind of ad hoc, unclear interfaces. But for the uninitiated, you won't see a difference. And yet many people will turn to PHP over Perl simply because it's just ubiquitous on web servers and so quick and easy to get things started with PHP. Perl is extremely powerful. I think in many respects, I would definitely prefer Perl over PHP, not just because I know it so well,

but there's some benefits to some of the things it does. I'm not going to get into it. I don't want to fight between languages. PHP is a great thing because it know it so well but there's some benefits to some of the things it does I'm not going to get into it I don't want to fight between languages PHP is a great thing because it does other stuff well but if you can't tell the difference from the outside then if you're in the inside you can easily tell the difference for pro 5 and pro 6 from the outside it's a little bit harder to tell the difference until you start getting into some of the more advanced features from the inside you're going to see huge differences. So they're definitely sister languages.

So you would look at Perl 5 code, and there's a lot of Perl 5 code, which if it's written carefully, will run the same under Perl 6. But the differences quickly diverge in the cleaner syntax of Perl 6, something we call invariant sigils, which really solves a lot of the problems that new developers in Perl 5 had. A lot of the things that are add-ons to Perl 5 today, such as metaprogramming roles, which is probably the greatest advancement to object-oriented programming since Simula 67, almost 50 years ago, that's going to be baked into the language. So many powerful things about it, which either don't exist directly in

Perl 5 or would be very hard to implement. Tell us about that, this roles thing. Okay, roles. This comes from Smallpox Style Traits. And there was a paper called A Brief Introduction to Traits, I believe is the name. And it was an introduction to solving a longstanding problem we had with object-oriented programming. So in 1967, Simula 67 was released, and that had classes, inheritance, polymorphism, encapsulation, and people generally agreed about all of that except for inheritance. Inheritance was such a problem. So many languages allow multiple inheritance, such as C++ and others, but you're often warned not to

actually use it other languages such as java ruby and others say okay multiple inheritance is such a problem we're not going to allow that at all but here's the alternative and they actually encourage the alternative the problem is the alternatives such as mix interfaces, they have so many built-in problems themselves that they didn't actually solve the underlying problem. So the traits researchers, we call them roles in Perl because traits is actually a term for a different thing. What the traits researchers did is they were funded to investigate the problem, come up with a solution. And what they discovered was classes actually have two roles. As an agent of responsibility, your employee class, as your system grows, has to take on more and more and more behavior. But if you're going to inherit from your employee class, then it's an agent of code reuse. And quite often for code reuse, we don't want all that behavior.

We just want little specific bits and pieces. And in fact, there's a language called beta, which was going to implement multiple inheritance. But when they researched it, they found out that almost everyone using multiple inheritance wasn't for creating more specialized classes. It was just to pull out bits and pieces of parent classes. So the reality is for code reuse, you actually want smaller code because you just want to pick out the bits and pieces you need. But for class responsibility, you need all of that. So classes actually serve to do a role, reuse and responsibility. And the problem we've had with inheritance and the solutions such as interfaces and mixins has been you need to decouple those. So roles has decoupled them entirely. And so classes are agents of responsibility. So an employee might have an employee number, but does an employee know how to serialize itself to XML or JSON? No, it doesn't. This is a bit of behavior which could beavors. Ruby mixins actually properly separate behavior

from responsibility, but unfortunately they implemented it via single inheritance. So if you mix in a couple of modules into your Ruby code and then you call ancestors, you'll find that it's implemented as a single inheritance tree, and then you wind up with strange bugs. So if you have duplicate methods in multiply inherited classes, the first class you inherit from generally wins. In Ruby, the last mix in that you've mixed in wins. With roles, it's completely different. It says, oh, I'm sorry, you have duplicate methods. They have the same name.

It's going to fail at composition time, close enough to the pile time. Most people won't notice the difference. It'll fail at composition time. It says, I don't know which of these methods you need. So you specifically say, I want this method from this role. I want this method from that role. And you don't have any of those composition issues that you have with multiple inheritance or mix-ins or some of the other solutions which are out there. There's a lot more I can say about them, but this is one of the finest things about roles. It cleanly separates class responsibility from code reuse.

And more and more developers are finding out that you can eliminate inheritance entirely and build an entire large-scale object-oriented system just by composing different roles and saying, I want this behavior, that behavior, the other behavior. And you get composition safety because you don't have to worry about method conflicts anymore. You don't have to worry about accidentally inheriting a method that you didn't realize you were inheriting.

And it makes things so much simpler. It sounds like a pretty big win. So is that available in Perl 6 today? It's available in Perl 6 today. It's available in Perl 5 via something called Moose Roles. There's some other roll modules out there. I have one myself, which actually goes back to the original research on this. There's some guarantees that rolls actually provide, such as being commutative and associative, basically mathematical guarantees to get around some of the issues that you had with inheritance and mixins. And different systems meet those guarantees in different ways. But it's available out there, but many other languages have this. I know there's been some experiment with Java to do this.

There's been some experiments with Python to do this. I'm pretty sure it's available in Ruby. JavaScript has something, I believe, called Juice, which I had heard about. I don't know how far along that is which also makes roles available so there's a wide variety of languages which have adopted it but how much people are actually using it is hard to say, but the Perl community has bought into it wholesale

because it tremendously simplifies your code and makes it much easier to understand Perl 6 sounds very experimental and research-oriented. Is it run by the same group of folks that are doing the Pearl 5 stuff, or are they also diverged? Yes and no. Does that help? Nope. Please explain. I'm glad I can clarify that. So Larry Wall, the founder of Pearl, has has shifted his focus from Perl 5 to Perl 6.

And many people now call Perl 6 Rakuda, just to distinguish it from Perl 5. Would you say Rakuda? Rakuda. R-A-K-U-D-O. Interesting. Earlier on I was thinking, man, maybe it just needs a separate word, like a separate term altogether. Yes, and I would like to see that term adopted a little bit more widely, but there's a lot of background to that. And Perl 6, the name's been around for so long that they've stuck with it. So there's that marketing thing about don't shift your name because you'll lose people.

So possibly that's some of it. Yeah. Anyways, you were saying? So Larry Wall has shifted his focus from Perl 5 to Perl 6 and has been pushing it forward. And it's just making tremendous strides. Damien Conway, he wrote Perl Best Practices and quite a number of other excellent books involving Perl, including Object-Oriented Perl. And he has also been doing a huge amount of work with us. But many people, such as Patrick Michaud, who is heavily involved with PHP, and others,

Carl Masak, many others have been heavily involved in pushing Pearl 6 along. Jonathan Worthington, he was a Pearl 5 hacker, but mostly focuses on Pearl 6 now. And he's been doing a lot of the work, putting it on the JVM and writing something called MoreVM. So there's now, originally it was a bunch of Perl 5 hackers. Now there's a completely separate community of people from a variety of different backgrounds. Many of them academic, many of them basically heavily involved in the real world who have been building Perl 6, many of whom have no background in Perl 5 anymore. So is Perl 6 out there in production, or is it still kind of at an experimental phase?

I do know there are some folks who have been using it in production. Generally, they're using this for smaller tools, the sort of small tools that you might build shell scripts for because that's a little bit safer, a little bit lower risk. Large-scale systems are generally not being built in Perl 6 yet. There is more work to be done with the final work for porting it to more VM and the JVM to finally get it production ready. There's more I can say about that, but I don't know how much I'm actually allowed to say simply because for the long time,

Pearl Six has always been promised by Christmas, but we just don't say which one. I'm reading some commentary behind the scenes here to sort of listen to you. By the way, I love that explanation of roles versus inheritance. That was really great. But some, some thoughts here from Reddit, and I'm not sure that's the best place to go for thoughts, but it seems like people have this huge question in the pro community about what's happening with Perl 6. And even specifically Larry Wall, you've mentioned a couple times, and whether or not they've questioned the code quality – or sorry, the language designs, not so much the code quality, but some other things happening there. It seems like, stepping back to earlier, you mentioned this,

maybe it's not so much marketing, maybe it's communication. And that's where I feel like having you on the show today and just sort of getting this bird's eye view from someone inside the community that's been there for a while that's sort of, as you said, by accident to a degree, a happy accident, that you can sort of disseminate this idea of what Perl 6 is going to be and what Perl 5 is doing currently because 3.1 is a tiny bit. You mentioned you had a role, a role, roles in Perl,

and I believe it's role basic. Is that your version of roles? Yes. There's a second traits paper. Let me see. Is it typed calculus? No. Traits, the formal definition, I think is the name, which despite the name, is actually a fairly easy to read paper, which unfortunately I consider to be the traits paper that no one has ever read but should.

And it's absolutely fantastic. And it clears up a lot of the communication. I've actually spoken with a number of the traits researchers to clarify some of the issues in there. And traits themselves still have some issues. I should call them roles just because that's what Perl does. They still have some issues because this is programming. And in programming, we don't have perfect systems anywhere, but they are the best thing to come along. And I have worked with so many alternatives and they do solve so many problems. But yes, I wrote role basic in an attempt to create a system that goes back to the original definition and truly respects some of the rules, such as being commutative and associative. For example, if you have a role which does JSON serialization,

and you have a role which does, I don't know, YAML serialization, and if you compose both of those roles, they should, it doesn't matter which order you compose them in, unlike, you know, inheritance or mixins, it's guaranteed you get the same behavior. Technically, it is possible to violate this contract with roles. Or if you have the role which does JSON serialization consumes another role which does marshalling, you might just decide, no, I'm going to consume my does marshalling role and that is going to consume the does JSON and does YAML role. So I'll get all of the serialization methods all at once. But in theory, according to the original traits research, it doesn't matter how you consume those, how you mix and match those. In roles, it is possible for that contract to be violated depending upon how you do it. It's unusual for this to happen. And dedicated programmers who know that different methods should actually have different method names

are really good about avoiding those problems. But there are still some subtle edge cases, but they are, in my experience, more than an order of magnitude less than you have the edge cases with mixins and inheritance. So you probably do most of your programming in Perl 5, right? Yes. And this role basic, is that what you use for your roles?

Or because you said this is your version of it. There was another one out there you mentioned, but I didn't catch that one though. I use, there's also a role tiny. I use almost exclusively Moose role because Moose is the most fully fledged object oriented system out there, and I'm not just talking about for Perl. Moose brings a lot of the power of what we would

typically associate with static languages to dynamic languages. So when I declare an attribute such as social security number, I can say a social security number is a, and then I can define a very rigid type constraint for what that social security number is a, and then I can define a very rigid type constraint for what that social security number is. And rather than embedding my code with a whole bunch of type checks everywhere, is a social security number really fitting the format of social security number? Are the first three digits allowed, first three digits or not? I can simply declare a social security type, have them provide the validation, and anything which consumes a social security number, it has to match that type or it's going to fail and this is something you often don't get with many dynamic

languages we tend to play fast and loose with our data but there's so many powerful things you can do such as lazy evaluation of attributes so you don't create the connection to the database unless you actually ask for the connection to the database unless you actually ask for the connection to the database or, you know, just being able to list all of your attributes. But on top of that, you have metaprogramming. So I use metaprogramming quite heavily. I built something called Test Class Moose, which is basically an X unit framework for large scale enterprise class databases, if you will. And it's being used more and more. And what I've done with the metadata system within Moose is I'm able to inspect the methods to figure out what test methods are available. I'm able to find out what attributes are available. I'm able to compose roles into things. So I can

have roles defining fixtures so I can easily load fixtures on demand. And if you've never played with metaprogramming before, it is hard to appreciate the power of it. And if you've never played with metaprogramming before, it is hard to appreciate the power of it. And once you play with metaprogramming, you never want to go back because it makes so many of your problems so much simpler. The cost is the software you build is simpler. It is easier to write. It is faster, right? It's a little bit harder for some other people to understand it because most people don't understand the concept of metaprogramming at first. It sounds like you also, I mean, you mentioned testing here a few times in that conversation, obviously when you're metaprogramming and when you have dynamic languages,

testing becomes a huge part of that assurance that things are still working the way that you wanted them to. You said you wrote a test harness that ships with the language. Maybe tell us about the testing story in the Perl community, whether it's TDD style or just what the community looks like as far as testing code goes. Perl has possibly, I mean, Ruby talks about themselves as being test infected and they have nothing on Perl. So CPAN, this is the central archive of Perl code that most developers tend to push their code towards. the tests for my code on all sorts of different flavors of Linux, all sorts of different flavors

of Windows, all sorts of different Macs, on AIX, on Solaris, you name it. My code is being tested there with tons of different operating systems, tons of different versions of Perl. And I find out very quickly which operating systems, which versions of Perl my tests are failing on. And this is for free. And this is the sort of thing that enterprise customers can pay hundreds of thousands of dollars a year for. And there are millions and millions, literally, of test reports out there on CPAN testers. And when you go out there and you pull up one of the versions of your module, and my version of this module, 1.14, happens to fail on Solaris with Perl 5.16. And then you can go, and if you've written your tests well for printing out good explanations of what's going on with your test, you can say, oh, now I understand what's failing. And even if you don't know Solaris,

you can contact a Solaris user or perhaps a person who originally ran it on their, what we call smoke machines, their smokers, and say, my module failed on your machine with this version of Perl. Can you help me with this? And you get this powerful free feedback that is virtually impossible to get otherwise. And anytime I upload a new module to the CPAN, I get hundreds and hundreds of test reports coming back very quickly. And it's just phenomenal. And I don't see that other places. If I want to install a module on my local machine, I can have the option to run the tests or not. So if I want to run the tests, I can see what's going on. I can give feedback to the module authors. It's very easy. And it's gotten to the point, it's very, very much frowned upon for popular modules to

be uploaded to CPAN without tests. And the test coverage is just phenomenal in many of these modules. And it really, it's nice for me as a developer when I'm recommending, you know, use this new module in your code base because it's going to save you a lot of time and trouble. And they say, well, is it robust? And I can say, look at this test suite, look at all of these test results and all these different operating systems, all these different versions of Perl, look at all those green bars there. And it's just fantastic.

So I love it. It makes me very happy. I did not know that about CPAN, that tester. What do you call it? The test smokers? The smokers. It's, oh my goodness, I'm trying to remember the name. It's something that I've taken for granted for so long, to be quite honest.

The CPAN reporters. I would have to go and look up the URL offhand. But you can go out there very quickly and see all of the test reports which are available for all of your modules. But this is free, and anything anyone uploads is automatically run through the system by just dedicated volunteers. So it's not something you have to sign up for. It's not something you have to ask for. It just automatically happens for you. That's awesome.

You know, when I was back in college and I was doing some Perl, I liked the language. I still like it to this day. I think I saw the value, especially in the regular expression stuff back then that just was so easy comparative to what I had done previously. And CPAN was always boasted as this great thing. Now, as a fledgling young programmer, I'm probably like 2001, 2002, man, I just could not figure CPAN out. I couldn't even get past the configure step to get that thing out there. I'm just trying to get somebody else's code on my system.

And I'm sure it's an isolated incident, but maybe give us some background on CPAN. I know that it's much touted as a great system. It sounds like that automated testing thing is really cool. Tell us more about it. So the CPAN is Comprehensive Perl Archive Network. And there's a module, cpan.pm, which comes shipped core with Perl.

So when you first download Perl, you can run the cpan command, C-P-A-N, all lowercase. And what you experienced was a longstanding problem. Today, what it does is it says, oh, this is the first time you're running CPAN. Would you like me to configure as much as I can automatically? You hit yes, and it magically works. That sounds great. That's not one of the problems.

I know. Basically, they took the trouble to make the pain go away. So I often install new versions of Perl. I'm playing around with different things. I set up cPanel for the first time. And if I select yes, occasionally it might pick a mirror too far away from me. But aside from that, it works beautifully and it's not a problem. You also have CPAN minus.

So app CPAN, so cpanmin.us, that's the site which has a very simple, that has a very simple command that you can run, which will allow you to install CPAN minus, which is kind of like CPAN, except it does even less. So CPAN, when it downloads your code, it will download all the dependencies, run all the tests, and then you have some dependency failing on a test, which is completely unrelated to what you're doing. Or CPAN minus will just take all the pain away and just build your code and install it for you very quickly. And it's very powerful. And most of the time it just works wonderfully. So we're actually winding up with multiple different solutions, depending upon what your particular needs are.

How thorough do you want your test coverage to be? Are you not worried about that? Do you want to just install a simple module quickly? Most of it's just painless and people don't have to worry about it anymore. So what you discovered was a longstanding complaint, but it pretty much doesn't exist today. Cool, cool. I just loaded up CPAN- and it redirected me to a GitHub page,

which makes me wonder, where are you all at with Git and GitHub and having code be publicly available on GitHub at least? Yeah, embarrassingly enough, I just had the same thing. Is that not supposed to happen? It wasn't happening a few days ago, so that makes for a very awkward turn for this conversation. Or a perfectly intended turn for this conversation. Yeah, in our eyes. So many Perl developers are heavily involved in using Git, so

my company actually offers Git training also, just because it's so incredibly popular. And it was interesting that, you know, I would have SVN available for a long time, and, you know, oh, you can submit patches to my modules, you know, via SVN or, you know, just using the diff patch command, whatever. And I could count on the fingers of one hand

the number of patches I would get per year. Since I switched to doing most of my development and sharing my code on GitHub, I'm getting patches all the time. And it's just phenomenal. And because the pro community is very keen about testing and documentation, I'm usually getting patches with full documentation, full tests. Or if they don't have them, people will say, this is just exploratory to solve this little itch that I have. What do you think? And it's a way of collaboration that just didn't exist before.

And I'm very, very pleased about that. Most of the real community has bought into it. Cool. And are those integrated GitHub and CPAN as far as publishing goes? You have what are called metafiles available in your distributions, which can say my bug queue is actually out on GitHub.

The actual base repository is on GitHub. So if you go out to CPAN and someone set up their metafiles correctly, you can just click directly on the source repository and it'll take you over to GitHub or click on the bug tracker instead of the built-in RT tracker that CPAN uses. It can take you over to you know github or click on the bug tracker instead of the built-in rt tracker that cpan uses it can take you over to the github track tracker or any other site you want it's not just tied into github specifically it's a generic system saying this

is where my you know source repository actually is this is where my bug tracker actually is and it just handles it for you but it's very agnostic about this. CPAN isn't tied into GitHub, but it's probably the most popular alternative today. We're going to pause the show for just a minute. Give a shout out to a sponsor. Statuspage.io is a new sponsor for us. We're glad to have them.

It's all about transparency during downtime. And the best way I know to do that is to use statuspage.io to create a status page for your app or your website. So you can have an always up and always on way to communicate to your customers. When you're in a bad situation, your customers can subscribe to updates.

You can broadcast upcoming maintenance windows. You can post updates minute by minute, hour by hour, keeping everyone informed, everyone on the know. Integration with services like New Relic and Pingdom allow you to show off graphs to your customers that they care about. You can even embed your system status within your actual app. Head to statuspage.io to get started.

It's free to set up. Launch it when you're ready and tell them that ChangeLog sent you. And now back to the show. So does CPN sort of act as a registry in that case then? More like here's where Perl modules go, and you can find and install new Perl modules via CPAN? Is that how that works? Yes, that is far and away the most popular option.

There's also metacpan.org. It's a search, right? Yes, and some people like that, Some people don't, uh, myself, uh, I think it's interesting, but I'm so old school and I'm so used to search cpan.org that I don't even remember that there's a www.cpan.org. I just hit search cpan.org. I look for the things that I want. I read about them. I read the test results. I read the code. Yeah. Okay. I'll use this. So in your community or in your this. So in your opinion, what is the state of the community, the Perl community, in terms of transitioning the open source

work they do have out there to GitHub? Because you said that earlier you do some Git training and stuff like that. What is the state of the Perl community as it relates to GitHub and open source on GitHub and just general availability of I think, what we see over the last three or four years, just more and more and more developers moving to GitHub as just a better way to socially code together. And Perl's been open source since the beginning,

so it just seems like a natural fit for them, y'all, to eventually move there. But what's the state? The way it's working right now is most of the tool chain available for Perl is centered around the CPAN. So CPAN is a central repository for the canonical versions of modules and people use GitHub for collaboration. I have a number of modules which are available out on GitHub for doing various things that I don't have the latest versions of those modules out on CPAN because I want what's on CPAN to be a little bit more stable.

And if I move it from GitHub to the CPAN and I'm not entirely comfortable with it, I might mark it as a developer release so that it won't be installed by default. But we use GitHub for collaboration, for sharing, for talking about new ideas. We use CPAN as the central repository so that when you want to install code or you want to manage your CPAN code via Pinto or something like that, that you know the one spot to go for that. That makes a lot of sense.

One last question, then we'll get to the close here. So it seems like each language, especially talking about web programming languages, they all kind of have their killer app. You know, Ruby has Rails. You Rails, you might say PHP has WordPress, JavaScript has Node, and Python has Django, and there's alternatives, of course.

Is there a go-to web tool or framework in the Perl community that everybody's using, or is it more kind of diverse? It's definitely more kind of diverse. There are a number of really phenomenal tools out there. So Catalyst has for the longest time been the default web tool. And many of the clients that I go into today are using Catalyst. And Catalyst is a wonderful framework, mostly based around the concept of MVC. But one of the things that differs from some of the competitors

and other languages, if you will, is that it's agnostic about the MV and C components, however you want to plug those in. Do you want to use DBIX class for your, you know, the back end for the ORM, which is going to be backing up whatever your model is eventually going to be? Do you want to use ROSE DB? Do you want to use something different?

What do you want to have in your view layer to present things to people? You know, from the HTML, you know, do you want to use template toolkit? Do you want to use template X slate? Do you want to use, you know, Mason? What do you want to do? It's however you want to set it up. So there's a bit more of a learning curve for that, but it means you can customize it for exactly what you need. There's other things which are extremely popular, such as Dancer 2 and Mojolicious, which have different philosophies, which are very easy to use. They're lighter weight than Catalyst. They're not as fully featured as Catalyst, but they are so easy to use and so powerful that I'm seeing more and more sites switch over to them, and they're really nice. When you talk about the ORM layer, DBX class is just absolutely

phenomenal ORM. Rose DB is also excellent. It's not as popular. It's just blazingly fast. This is if you like ORMs. I know that not everyone does. We have an embarrassing richness of powerful tools because the pro community has been around so much longer than many of the other communities that we have a number of very mature products out there. But unfortunately, that means if someone says, what should I use for writing this brilliant new website that I have? You said, well, you've got this, you've got this, you've got this, and all of them are excellent. All of them have pros and cons. And a lot of people, I just want that one thing. And they just want to be told what to do. And that's a little bit harder to do with Perl because we have an embarrassment of riches, if you will.

Excellent, excellent. So just to preempt the haters, yes, I realize that Node is more than just a web thing. I just want to get that out there in case people thought that that was what I was trying to say. Very cool. Man, it sounds like you guys got a lot going on. Every time I talk with somebody on this show, I end up being like, man, I got to go look into what is going on in this community. So, Ovid, you did a great job representing Pearl. You said you do consulting.

You have a book. Anything you want to plug or promote while you're here? I would say that our company's website is allaroundtheworld.fr. That's because we're based in France. We do Pearl Consulting. We really specialize in going into companies which have older legacy systems and rebuilding them, testing them, making the modern systems easier to work on. We offer database training, Git training. I also teach companies how to use Agile appropriately or if they should use Agile because that's not always true.

That's true. It's kind of a, oh, goodness. We could spend easily a couple of hours with me going off about why Agile is wonderful and why it is not wonderful. And I would follow you. Both ways? Yeah, because I have some opinions there as well. I'm a strong, strong Agile fan, but it's not always the right choice. That's right.

So we do a lot of things. Mostly it's database get training, teaching testing, and particularly myself and our other associates going in and fixing people's legacy Perl systems and making them easier to use. It's amazing how much work there is there. Any particular repos you want to mention that you've got on GitHub or anywhere else that you can use some extra firepower behind, like some attention to?

Oh, my favorite one is unfortunately a private repo. It's a project code named Vir, which no one's seen, but I've talked about it a lot on my blogs. I'm building a text-based MMORPG in Perl. When's that going to get out there? By Christmas? By Christmas. By Christmas. So when's that going to get out there? I'm hoping to have an alpha out by the end of next year. We actually might have a new developer being pulled up in on it this year. There's actually been MMORPGs written in Perl before, but this one, I found an interesting

niche in the market, which is completely uncovered and which was a lot of fun. So I'm just building a science fiction world, a true RPG, not one of these things you just click around on like bulletin boards on the web. But it's text-based. So I'm having a lot of fun with that. Otherwise, I would tell people check out my Test Class Moose repository if you are interested in Perl and you need to build a large-scale test suite. It's much, much better than many of the other alternatives out there.

For the same reason, you wouldn't build a huge website today without choosing an appropriate framework. You don't want to build a huge test suite without choosing an appropriate framework. We can't, we can't obviously close this show unless we ask the, the notorious question, which is who is your programming hero? And I figure with some of the names you've mentioned today, you probably either will repeat them or you'll have new heroes to mention.

So let us know who your hero is. Oh, you're not going to believe me. My programming heroes are my COBOL professors in college. The reason for that is, so my Java instructors, I remember my very first Java instructor, she was fresh out of uni and she had trouble explaining the difference between a class and an instance. And it didn't appear that she was a bad teacher.

She just seemed a little confused on the concept. My second Java instructor, I accidentally turned in some code with some JUnit tests, and he was confused and kicked it back and said he didn't understand what that was. I've had this happen with professors in a number of different programming languages who just didn't have real-world experience. But the COBOL teachers, they had actually come back in from the field with many, many years of experience and were able to give a class full of students who were often, you know, not very interested or, you know, not very responsive, excellent real-world

descriptions of what you need. And I still remember the time I was trying to sign up for a C class at a uni, and they told me, we don't offer C anymore because the future is object oriented and C is obsolete. Yes, completely ivory tower. But the COBOL developers, the programmers, the professors, they understood that, okay, it's not the most popular thing out there, but they had tons of real world experience, which they were able to communicate in a way that my other professors didn't. And they were some of the best examples I had of what we actually need out there for teaching the next generation of students. The combination between deep theory that is really useful at surprising times, but the real world pragmatism of I got to get stuff done. So they are my programming heroes, even though no one knows their name, no one cares about them.

They're the ones that we need to see a lot more of. You know, often, you know, teachers end up being heroes anyways. And that's just a good thing. At least, you know, on this show, reach back out to them. I wonder if they happen to know that they're your heroes by any chance. I should find out and contact them. What did you say? I said I should find out and contact them at some point.

Yeah, because anytime you've touched somebody's life, it's nice to know because it's sort of like this pay it forward for teachers. They don't always see the fruits of their labor. They don't have the luxury of instant gratification. It's sort of like plant a seed and it grows over years and years and years. And oftentimes that person goes on to do great things and I'll be nice to that person. But I know that I've got a couple of years like that. So just saying.

But Curtis, it's definitely been a pleasure having you on the show. I think that you've given Jared and I some food for thought so to speak on the Pearl community and the Pearl ecosystem and how we can support that in our own way here at the ChangeLog to just help with this communication and marketing divide of Pearl 5 versus 6 and just in general what's happening.

It seems like you've got a lot of fun, great things happening that just need maybe a clear... I don't even know how to say it, but I'm sure there's some way we can help. So we'll do whatever we can to help you and help the pro community. We do want to mention a couple sponsors that helped make this show possible. Before we close out, CodeShip, Rackspace, and StatusPage.io,

all great sponsors of the show. We couldn't do it without their help. So Curtis, Jared, let's say goodbye. Adam, Jared, thank you very much. I had a blast. All right. Guess no bye from Jared. I forgot to say goodbye. I had to say goodbye real quick.

Goodbye. Don't worry about it. Oh, I had my thing. You've got to include that in the clip. I was muted. In the podcast. I was muted. I said goodbye to myself on mute.

That's funny. I'm like, I felt like I said goodbye.