Stevan Little on Moose

Posted on Monday, Jul 12, 2010

Show Notes

Recently I talked with Stevan Little about the Moose project. You can listen to the interview, or, thanks to cPanel, you can read the transcript below. Transcript

Josh McAdams:

Welcome to Perlcast. This is your host, Josh McAdams. I’m here with an interview with Stevan Little, the creator of Moose.

Heather Hendrix-McAdams:

The transcription of this show was underwritten by cPanel. cPanel is currently hiring talented Perl developers. To Find out more, visit jobs.cpanel.net.

Josh:

Perlcast back finally, and I’m with Stevan Little. Stevan Little is the creator of Moose. Welcome to the show, Stevan.

Stevan Little:

Thank you, Josh.

Josh:

Thank you. Thank you for being on. I know most folks in the Perl community they at least know your name and they know you created Moose, but that might be all they really know. So can you tell us a little bit about yourself, maybe how long you’ve been programming Perl, where you work and why you got into open source code?

Stevan:

OK. well, I’ve actually been in the web field since approximately 1998. But I actually was mostly a JavaScript programmer for many year. Then about 2002 I got hired on to Infinity Interactive, where I work now. And they basically hired me on to do Perl. So I’ve done Perl I guess about eight years now.

Josh:

What got you into the open source stuff?

Stevan:

Well, we’re a small consultancy, and we pretty much wouldn’t be able to do what we do if we didn’t use open source. Perl and all the CPAN and Apache and things like that, it really allows us to build applications for reasonable prices for our clients.

After a while using a lot of open source we decided we wanted to give back and I think I uploaded my first CPAN module in 2004 and after that I was addicted. It’s a fun hobby.

Josh:

Well, one CPAN module that you’re very noted for is Moose, but before we get to that, what was your first CPAN module?

Stevan:

It’s a module called Tree::Simple. It was a n-ary tree and I used Caml Case and all sorts of stuff coming from the JavaScript world. I thought that was the way to go. It still works today. We actually still have it in a couple of our prod systems. But it was the first one, the first hit.

Josh:

Nice. Nice. So we’re here today to talk about Moose, and that is a very popular project now. But I have a feeling that some of our listeners have either possibly never heard of it or at least not know about what it is. Could you give us a little description of Moose?

Stevan:

Sure. Moose is, we call it a post-modern object system. That’s mostly sort of for fun. But essentially what it is, is it’s an attempt to make Perl object-oriented programming a little bit more modern, to give you some features that you get for free in a language like Java or Python or Ruby. But bringing it into Perl, and we borrowed a lot from Perl 6, and we really try to keep the Perl-ish scaling at the core.

So the real goal that is to make object-oriented programming less tedious, less of the DIY approach that is out there with a lot of the Perl OO.

Josh:

Got you. And you called it a post-modern object system. That’s kind of hinting that Perl had a modern object system at one time, which I think people would be shocked to call anything in Perl a modern object.

Stevan:

Yeah. It’s a bit of a joke. It makes reference more to – Larry Wall had a great article. I believe it was in the Linux World, where he called Perl the first post-modern programming language. We took it from there. It’s one of those things that people scratch their head at. It maybe at least gets them a little interested. So they say “What do you mean by post modern?”

It really is modern, however you want to look at it.

Josh:

So whenever you set out to write Moose, did you decide right then, OK, I’m going to write a more convenient objects mechanism in Perl, an object framework in Perl? Or did it just organically grow?

Stevan:

It came out of the Pugs project, which is a project that in about 2005 started. It was Audrey Tang who was had decided that she wanted to implement Perl 6 in Haskell. So it was sort of a very fun project. Audrey coined the term “O-fun,” optimized for fun.

And lot of the goal of the project was to get some juice flowing back into the Perl 6 community and really get a working or a semi-working implementation so people could play with it.

One of the things that I did in that project was to prototype the object system for Perl 6. I read over the Apocalypse 12, read up on a number of different object systems in different languages such as Smalltalk, CLOS, which is the Common Lisp Object System. Objective fees, objects run time, Ruby, Python, all those things. We were doing a lot of research at time and we tried to put a lot of that stuff, a lot of the good ideas, into the Perl 6 object system.

And then basically as the Pugs project started to peter out, I found myself going back to my work code, which was your basic vanilla Perl 5.OO. And I really craved all the features that I had been prototyping.

So months here and months there, I fiddled around and I finally came up with a module called Class::MOP which is basically the basis on which Moose sits. And so a couple months after Class::MOP, we released Moose and sort of got running from there.

So it really came out of the desire to use a lot of concepts that I was seeing in Perl 6 and other languages that I was looking into. Even Java. W pulled a lot of stuff from Java as well, and C#. There’s a lot of good ideas out there and we tried to really bring them all in there and keep the core kind of Perl-ishness that Larry had designed into the Perl 6 object system.

Josh:

I don’t want to put you on the spot too much because I didn’t prep at all for this question. But you did say that you pulled a lot of the best things from different languages and one of the languages you mentioned was Java. I know Java’s an object-oriented language and it does have some good features, but could you just give some example of possibly on of the good things that Java had that might have influenced Moose?

Stevan:

I’ve heard Java called a manager-friendly language. On some level, people or managers or higher ups start think that the programmers are just replaceable, because there is this one right way to do it in Java, there’s the right way and the wrong way.

There’s a consistency to that that. When you walked into a Java programming situation, there’s a clear way to build your class attributes. There’s a clear way to define methods. Object construction is very worked out. There’s no mysteries there.

Some of the things about the older school Perl OO, if you surf around CPAN a little bit and you start to look at some of the OO modules, you might see many different ways of building objects. Damian Conway’s book was a great book, and it showed a ton of different ways to build different objects.

And there’s interesting aspects to that, but on some level, the consistency. Java does it a little bit too much, maybe too draconian about everything is consistent, but there’s a value to that. The larger your project gets and the larger your team gets, the more important it is for the code to be readable across all the different developers and be consistent across all the different developers. Not so much because they are replaceable but more just so that everybody who can get on the same page be able to understand one another’s code.

Java is very strong in that direction, and actually that’s some of what we were trying to do with Moose, too.

Josh:

That’s perfect, and that’s an excellent segue into what I was going to ask you until I changed my mind on a question. And that was just to tell us a little bit about Moose. Because whenever I’m a Perl programmer and say don’t have an object system other than just core Perl, I’m going to create a method probably called “new” maybe not, that I use as a constructor.

I have to pick how I’m going to take arguments into that, whether it’s a hash or an array or a scalar or some data structure, and return that. Every component is negotiable in building an object. So what are those standards that Moose does? What can a Moose developer expect to do?

Stevan:

Well, in Moose, we provide a consistent way to define object attributes or class attributes, as everybody calls them. Basically, the slots in your object. On the deep core, we use a hash-based object system, but we provide a way to build metadata around the different attributes that you’re going to have within your object.

Then the constructor that Moose provides adds to that by making sure that you’re checking all the attributes, make sure that they’re pathed, if they’re required attributes, that the requirements are satisfied. There is a convention for Moose to pass a name value to the constructor that is actually overridable if you want, but we use that as the base convention to start off of.

Moose also provides what’s called a build method, which is a way of initializing objects in certain orders. Every build method within your class hierarchy is called in the correct order, and then in the inverse, all the demolishment, which is essentially the Moose version of destroy, are called in the correct order as well. We sort of formalize and make consistent object construction, object destruction, and defining the slots in your objects.

With the older Perl OO, good Perl OO programmers would have done this themselves. They would have had consistency there, modulate class accessor and things like that. They sort of pushed you in a good direction with that. But Moose provides a larger framework for that, so it’s literally all there for you, and it’s checked as well as it can be checked. But there actually is still some underlying freedom if you want to mess with it.

Josh:

So you do have these defaults. You hinted a few times in the description of the framework that there are ways to bend Moose to do it what you want it to do, or even to extend that. I’ve peeked and seen the Moose X namespace. What are some of those hooks and the flexibility that you provide?

Stevan:

This is something we stole from CLOS, the Common Lisp Object System. It’s called the MOP, which is a meta-object protocol. Essentially, what a MOP is, is a formalization of the object system. It’s a very low-level API that defines the object creation process and the class creation project.

What we did, was we broke that up into several different - we call them sub-protocols. So we have a class protocols. You can actually sub-class the meta-class. It’s a little confusing. Each class has an associated meta-class, which basically defines the guts of that class. You can actually sub-class or apply roles to that class. You can hook. You can get into the hooks during the class creation process.

Additionally, there’s an attribute sub-protocol, which when you define an attribute on a class, which then defines a slot that ends up in the object instance, there’s a number of hooks in there. That’s actually the most popular way to extend Moose, is to provide extra implements on the attributes.

We also have a meta-protocol to find methods and to be able to hook into there. So a lot of where the extensions come from are the underlying object system itself has a number of hooks and a number of places where you can inject your code into there and during the class creation process, you can produce different results.

One of the most popular ones moved into core last year. If you were to store, in one of your attributes, an array ref or a hash ref, basically a native Perl data structure, we allowed you to delegate to some of the built-in functions of Perl.

So you can perform delegation just like you would with a normal object-to-object relationship. You can perform delegation with the underlying array ref or the underlying hash ref or the underlying code ref. It basically allows you to make a very declarative way to define an API to access some of the attributes that might have collection in the hash or in an array ref.

Like I said, it was so popular that we basically decided to core it. Along with that - let’s see, what’s another good one?

David Rolsky, who’s one of the core developers, he added a way in which you can define class-level data, so class attributes. He extended the class-attribute protocol to basically allow you to put in class attributes. I’m blanking on the other ones.

Josh:

No, no, that’s perfectly fine. That’s two very good examples. So that’s a really good description of the framework, a really good description of ways to extend it. But you had actually mentioned earlier that there are other frameworks out there. Damian Conway has the inside-out objects framework that came out in his “Perl Best Practices” book. A lot of people heard of that. How does Moose compare to the other object systems that are available for Perl?

Stevan:

I think a lot of where Moose differs is in the scope of what it was trying to do. If you look at the old standby, which is Class Accessor, which is a pretty popular framework, the majority of what that was attempting to do was to automate accessor generation. And it provided a very simple constructor that essentially collects whatever pass in. But it really didn’t try to reach too much further than that.

Some other things, like Class Method Maker, provided a lot more functionality but still is on some level I was an accessor generator.

Inside-out stuff was essentially a very different approach, because it really tried to redefine the way Perl instances - the structure of them, the underlying structure of them. And there were a couple actually really nice modules that came out of that. I believe Class Inside-Out was one my favorites.

Still, a lot of what if came down to was the accessor generation, which tried to build upon the existing Perl OO system. What Moose really tries to do is take that Perl OO system, define a formal structure around it, and extend it to build a whole API on top of it. So really to give you a real full, true dynamic object system underneath, which really extends much beyond accessor generation.

We also have a things called type constraints, which are basically little snippets of code that do validation. You can attach them to your attributes. There are a couple of models out there that allow you to use them when checking your method parameters, things like that. That was something we added on that most of the other object systems don’t have.

The whole concept of the meta-object protocol, meta-classes, and the attribute meta- objects, all that of underlying a deep voodoo, if you will. It’s sort of a little different scope and a very different approach to essentially, on some level, trying to both do the same thing which is make the tedium of the Perl DIY OO system, make it a little bit easier, make tools a bit faster, just a little bit less tedious.

Josh:

Right and there tedium to other languages OO systems. I write a lot of Java code nowadays, I’ll shamefully admit. And writing the getters and setters for that is an exercise in pain, for sure.

You did mention the ability to validate the arguments brought into methods. It sounds similar to almost static typing language but it also seems a lot more than that really, I guess, Because you can do more than just make sure that it’s a number. You can do any kind of validation that you want. Is that…

Stevan:

Yeah, what we tried to do is we tried loosely model the “type” system that is sort of core Perl 5. It is to some degree based on a lot of the type system work that was done on the Perl 6 project, as well.

It’s not a true type system in the sense, like your Haskell or OCaml or something like that. And certainly we can’t statically check at compile time. But it’s a way to inject these little checks into a method validation or method arguing validation, attribute validation which, will then also check with the constructor.

There’s a lot of other modules out there on CPAN that do these kinds of things that do constraint checking and do validation support. We tried to push it into the object system itself.

It makes it almost like a type language, but we’re not a draconian as a true Java or C#, because we’re not checking it with a compiler so strictly. And you have mild flexibility with Moose to define your own subtext of existing types and add to the system as much as you want, as well.

Which you can’t do - well, you can do that in Java and C# by actually adding additional classes, but we have a bit more freedom than that.

Josh:

Got you. And so one of the questions I was going to ask about Moose being a heavyweight system and things like that but it sounds like on the actual writing of code aspect of it that Moose is going to make your programs much more succinct and get rid of a lot of the boilerplate. Is that a true statement?

Stevan:

Yeah. I would say that’s a true statement. At work we started Moosifying, we call it, some of our older systems fairly early on, obviously. I wrote it, so I trusted it. So we started doing that and to some degree with an older code base, a fair amount of the Moosification is actually deletion of code. So those hand-written accessors, those hand-written constructors, hand-written validation, things like that that stuff starts go away when you Moosify more and more.

I think it’s safe to say that Moose code in the end ends up more succinct. It’s declarative, and declarative code just by its very nature tends to be shorter than more explicit code.

Josh:

Yep. And so you mentioned that you went and Moosified older code. So you can have regular Perl objects, Inside-Out objects and Moose objects all working in the same ecosystem. It’s not going to be a big deal to mix those, right?

Stevan:

Right. That was one of the core requirements for Moose when we started building it and that was really to make sure that it played as well as possible with both existing Perl OO systems that are out there, like the Inside Out system, and to also make sure it played well with very popular modules that were out there.

If you couldn’t still use all the CPAN with Moose, you would lose a lot of its value. And you can think of it as incrementally drinking the kool-aid. I actually have code bases that have been around since before the days of Moose and some of the early code bases that I Moosified that are still only partially Moosified.

We only went as far as we really needed to. Some of the deeper layers of these systems really didn’t need to be changed. It stayed the same. And as long as we could still extend them with Moose and we could still delete to them all those kind of things like that.

It’s a very important thing for me and for the core of Moose to basically not to alienate all the thousands and millions lines of code that are out there in CPAN, and that’s one of Perls' greatest assets.

Josh:

So when would be a good idea to use Moose? Is there ever a reason? If you are using Moose and you are committed and you believe it is a good tool to use, is there ever a need to use an old Perl object that’s hashed and said, or is Moose pretty much just a full replacement?

Stevan:

Well, Moose does have a startup time penalty. A lot of that is for the initialization of the object system and each class define. As you define a class it will create a meta-class and the meta-class will have the attribute meta-object. You’ll have all these objects that are created at, not quite compile time, but right after compile time.

So there is a startup overhead associated with that, and then also obviously we’re creating these objects so there’s memory in the CPU involved, as well. When you are in a restricted environment – which hardware is pretty cheap these days. People still have business requirements that require them to work on smaller hardware and with less CPU and in memory. You know, in those situations Moose is really appropriate and that’s really where the requirements dictate that you really need to keep it slim.

A perfect example actually is the Plack project that Miyagawa is working on. If that project used Moose, it would restrict the adoption of it. The project is an attempt to sort of define a consistent and clean interface between web servers and web applications, which means you have to not only work in Perl but PSGI and also in vanilla CGI and also in a number of potentially weird and interesting environments. It makes more sense for Plack to stick with the slim DIY OO system at its core and therefore be able to use in both places.

So there’s reasons to go back and forth. But generally, it comes down to can you bear the compile time startup and can you bear the extra CPU and memory, essentially. And even with that we have a system module to Moose which is called Mouse. And it’s actually has been adopted by a number of the Japanese Perl hackers. They’ve essentially taken it and running with it.

That is essentially it’s a pared down version of Moose that doesn’t provide all the underlying meta-framework, and really just has the sugar layer and gives the illusion of Moose. So there’s a fair amount of features but with much less of the startup.

It does pin on Excess, which of course in some cases that’s not possible, too, but that’s an alternative for part of your system. If part of your system needs to live in one of these restricted environments, then Mouse is a possibility.

Josh:

So as far as maybe strategies – I guess to rephrase the question that I have in my head. Are you guys trying to work to make that startup time of Moose faster? Or is it like, just go with Mouse, or go with the other object systems instead, because you’re always going to have to pay the penalty of this startup.

Stevan:

Well we’ve been working on this. It’s been a long backburner project for a number of core developers. A lot of what it comes down to is, once you decide that you need a lot of the dynamicism that Moose provides, you have to load things.

Some of the different solutions have worked to try and be a little bit more lazy about when it creates meta-objects. Which like I said are memory hogs and involves CPU usage. Some people have tried by caching them, or different things like that.

So we’re working on a number of different solutions. But in general one of the things that we’ve always done from the very beginning with the Moose project is, we optimize first for correctness. We really try to avoid premature optimization.

So we optimize for correctness first and for speed afterwards. And actually if you look over the course of the years that Moose has been there, we actually graphed out memory usage and startup time at one point, and we’ve actually stayed reasonably steady for maybe the last year and a half or so. But we’ve consistently added features.

So we’re always trying to keep it under control and not let it get too crazy. One of the things that’s helped us for instance, reducing 5.08 and 5.10. In 5.10, Perl 5.10, they added the MRO, which is the Method Resolution Order. That was something that we beforehand were doing in pure Perl, and then in 5.10 made it’s way into core.

So that was a fairly significant speed-up and reduction of some overhead. Because some of that stuff was going into core. I know there’s a proposal out there to put a class G word into Perl. That might get us some underlying cooks in the interpreter. So there’s a number of possibilities out there. We’ll make sure, exploring all of them.

Like I said, we’re optimizing to make it work. To make it work correct first. And we’ll get to the speed later. We’re hoping that Moore’s Law will catch up, and we’ll have a break.

[laughter]

Josh:

That’s good. And that addresses one of the criticisms I’ve heard of Moose, is the startup time. And another I’ve heard, but I hear it about every big Perl project, is that it installs half of CPAN. And I don’t know how many dependencies Moose actually has. Is that true?

And I’ve actually even heard somebody at YAPC this year say that they were always happy when something installed a lot of CPAN, because that meant that there was a lot of good code reuse going on. So what’s your take on that?

Stevan:

Well I actually looked on – you can click on it through CPAN. There’s a dependencies link on search.cpan. And I calculated it. And it’s about completely all the way out to the very end, so dependencies of dependencies of dependencies.

Moose actually has only 14 dependencies. This is working off of Pro five PAN. Though we do depend upon – there are other modules listed there but they’re actually test more, test exception, and all the modules that they depend upon.

And I believe there’s also class C3, is a dependency. But it’s not a dependency in 5.10. So in a reasonably modern situation of Perl 5.10 or above, it’s only about 14 dependencies.

Now that’s not to say that it can’t be a pain to install Moose. I’ve actually run into issues with it myself, in setting up new prod servers for work. We’ve run into situations where we have older Perls that don’t have updated test modules. And when you install Moose, if that has to install and test more, and that has to install a new test exception and all their dependencies, that can actually get to be a pretty good sized dependency chain.

And I’ve had that take upwards of a half hour sometimes, for everything to come in and be installed, and everything like that. So it’s actually like you said, it’s updating a lot of core things.

If you were to look at sheer number of modules that depend upon test more. Or modules that test exception on CPAN, there’s a really good chance that if you’re not working with a fresh installed Perl, you’ll actually have the latest version of that. Because just about everybody depends on it, on some level or another.

So the reality is that Moose actually has very few dependencies. And actually, if you look at the ones that are there, a fair number of them are actually – what’s the best way to explain this? They’re sort of workarounds for weirdness in the core language.

So for instance, we have the Try::Tiny module as a dependency. Which is an excellent module. It cleans up exception handling and handles the $@ symbol and makes sure it’s properly localized and you never lose an exception that’s in there. So we bucket into core Moose just to make sure there are exception handling that’s consistent throughout.

There’s also another module called Devel::GlobalDestruction, Which is a very simple module. All it does is give you a flag that tells you that Perl is in the global destruction phase. So when Perl interpreter is quitting, and it goes to destroy all live objects. That’s a very different time than when it’s destroying it on scope exit. So we have a module and that sort of handles that. That’s a very small dependency in the grand scheme of things.

Josh:

A few questions ago, you had mentioned Dave Rolsky as being one of the contributors that created a module that eventually got moved into the core. So I’m guessing you don’t work in isolation on Moose. Who all works on the project? And what are the roles there?

Stevan:

We’ve actually got a fairly good core team. We’ve attracted people over the years. Dave Rolsky is one. He’s known for the Date Times project. He’s actually done a fair amount of core refactoring. I think that he’s actually, if you look at the “get blame” output. He’s second only to me, in terms of the number of core lines.

He actually also got the TPF, the Perl foundation grant to write the docs, which was a huge, huge thing. Because I’m not a very grant foundation writer.

We also have Shawn Moore. He works at Best Practical, the creators of RFP. He’s done a lot of core work and a lot of work around roles and really improving the role system. Ricardo Signes, of the Email::* fame. I think he’s pretty much maintained the entire namespace. He’s also a recent pumpking. He’s a contributor of a number of features. He helps guide the ideas.

Hans Dieter Pearcey, he’s also a core member. He’s involved pretty much – I think he’s got his fingers in about every Perl project out there. He was one of the people who helped core that module that I was talking about.

Jesse Luehrs, who actually works with me at Infinity Interactive. He’s actually been doing a lot of deep core hacking lately, fixing parts of the object system that you will hopefully never see but need to work right.

Florian Ragwitz is also a member of the team. He’s also a Catalyst core developer and he maintains the MooseX::Declare module, which is a very sugary version of Moose that uses the development declare module. He’s also been doing a lot of our releases lately.

Chris Prather who’s actually been around since the very early days of Moose and he’s contributed a number of Moose six modules and a number of ideas and he’s just sort of been there from the very beginning.

Josh:

And he is insane. He has also volunteered to do a workshop and a YAPC, to be the host. Yeah. [laughs]

Stevan:

He runs the Perl Oasis, which is the Orlando Perl workshop which is a great workshop. It’s in January in Orlando. It’s a perfect time to go to Orlando. And if you live in the north like you and I, it’s perfect time to get out of the snow.

Josh:

Absolutely.

Stevan:

But yes, he’s actually a very prolific community member. And lastly, no, two more people. There’s Yuval Kogman. He’s also involved in just about everything out there. He’s actually been involved with Moose since the early days of Pugs, so the incubation period. If you have an issue with an object system named Loose, then Yuval is the person to talk to because it was his idea to call it that.

And then lastly Matt Trout. I don’t know if Matt contributed much code but he’s been a voting member of the Moose cabal since 1.0. He was very early adopter and shaped a lot of these early direction of the design of Moose and the core ideas that were in it.

These guys were the core contributors, but we also have a lot of other contributors. They’re all listed in the pod documentation. I can’t think of everybody offhand, but Moose has kind of grown community projects.

This is something I’m very proud of. I haven’t really contributed more than a couple lines of code in the last six months or so. Because the other members of the cabal and the community at large has run with it. So it’s grown beyond me, which I am very proud of and become a real community driven project.

Josh:

That’s excellent. It’s always great to get a community together and that’s a huge, I mean, just the core developers you mentioned there, that’s an impressive group of people and the greater community at large. Whenever you said that you haven’t written or have written very few lines of code in the last six months for it. Actually I notice it’s not even under your name in CPAN anymore. Jesse Luehrs?

Stevan:

Yes. Well, all the members of the core team, we all have co-maintenance status through CPAN. Dave Rolsky released probably a good 20 or 30, probably more than that, 40 versions of it. Florian Ragwitz has been doing some lately. And Jesse is the last one last one holding the hot potato, I guess, for the last release cycle.

Josh:

It’s great that a project is supported by that many people. It’s really good and that does kind of lead into the question I was going to ask you. With that many people there has to be new features and work going on constantly with it. What do you guys have planned?

Stevan:

Actually, we’re sort of stabilizing at this point. I always wanted to make sure that the Moose feature set was – I didn’t want it to have “feature-itis.” I didn’t want it to start doing things that really was out of the scope, out of the realm of responsibility.

So we’ve always tried to keep a fairly good hold on the core features, and really allowed the MooseX extension name space to be where not only where people can add features that we don’t feel fit in the core, but also we can prototype features.

So good ideas, we usually encourage the person with the good idea to actually write a MooseX module and to extend the core with MooseX first, and then if there’s enough adoption and if it proves itself really well, then we bring it back into the core. We’ve only really got this one module at this point but we are talking about a couple other ones that are out there and bringing them back.

One of the key things, Moose is not like your normal CPAN module, where’s it’s really just sort of an API or an abstraction around a concept. It’s really sort of a language extension.

So designing Moose is not entirely unlike designing a programming language. I learned a lot watching Larry and Audrey working on the Perl 6 project. Really tried to get a lot of the good ideas that Larry has had over the years and keeping that spirit of Perl-ishness at its core. But also we want to make sure that it’s consistent. It’s internally consistent with itself and the features all fit in there nice and snuggly.

Like I said, if you want extra stuff there’s always MooseX. There’s plenty of modules out there already and there is so many different ways that you can hook into that core that if you really want a very customized version of Moose, it’s quite possible to do that.

Josh:

That’s all the questions I have. It’ll probably be a good idea to let people know where to go to get started if they wanted to learn about Mouse. The places I know are the Moose Manual on CPAN, and then I think if you just search for Moose on the Infinity Interactive site. Did you want to fill us in on more?

Stevan:

Yes, we have the Moose.Perl.org domain. So that’s essentially a site that collects links. We have links to be number of articles that people have written and blog posts people have written about Moose. We try to keep a lot of the presentations people have given at various conferences about Moose, which are always a good way to learn. And then again, Dave’s excellent Moose Manual that he wrote is an excellent place to go.

We actually were, what we did, Dave did a Moose workshop at YAPC this year and we’re actually talking with the Pittsburgh workshop guys about possibly doing another workshop there, a Inter-Moose that Dave Rolsky does. And then Shawn Moore and Jesse Luehrs are thinking about doing an advanced Moose version there. If you can come up to the conferences and the workshops we try and do a lot of stuff there, as well.

And again, the manual. I can’t really stress enough. The manual is great. We openly encourage contributions for that, where people want to help improve on that. The IRC channel has Moose on IRC.Perl.org. There’s also great place. And the mailing list. The mailing list has been getting a lot of traffic lately, which I’m very happy about because that means we have a lot of indexed content in there.

And most of the core people and lot of the just outside of core people who also do a lot of contributing. They’re all on the IRC channel and all on the mailing list. We try and we back overflow and for months. There’s a couple people who keep on those two channels as well. Make people’s questions are answered there.

Josh:

Great. Well, Stevan, thank you very, very much for agreeing to the interview and thanks to the Infinity Interactive for letting you release Moose.

Stevan:

Thanks for doing the Perlcast and thanks for getting it back.

Josh:

I’m excited.

Stevan:

Thank you and congratulations on your new baby, as well.

Josh:

Yeah, and she probably was crying in the background at one. I have headphones on so I don’t know if she was or not. If any of the listeners heard crying, it was Clara.

Heather:

We’d once again like to thank our transcription underwriter, cPanel. cPanel is currently hiring talented Perl developers. To Find out more, visit jobs.cpanel.net.

Guests

Hosts