Traits vs Roles

In natural languages lot of objects have multiple names. For example I am known on CPAN and IRC as perigrin, I am know to my friends and family as Chris, to the TSA as David, and to my children as Daddy. Each of these different names illuminate a different context or role that the object, me, is thought of or used in.

Recently there was a debate or argument about the concept of Traits vs Roles in #moose. This has been a issue for a good long while. Ultimately the answer is that Traits are another name for Roles. Just as I am both perigrin and Chris, Traits and Roles both refer to the same concept but with different context or conceptual baggage allowed.

But this isn't really a satisfying answer for a programmer. Two names for a single concept isn't very efficient, especially if the differentiation isn't very concrete. For example Chris vs perigrin is (in theory) cleanly delineated by Offline vs Online. I think a little history will help explain the reason that these two names exist and are adopted by the Moose community.

First the concept of Roles is generally based upon a paper Traits —Composable Units of Behavior. For this paper they created an implementation of what we call Roles for Smalltalk 80, and named them Traits. So outside of the Perl world, Roles are Traits. This is the first point of confusion.

Next, like many good things in Perl these days, Traits and Roles started in Perl with Perl6. Roles in Perl6 are effectively identical to Perl5, however Perl6 has a specialized concept under the name 'traits'. According to Synopsis 06:

Compile-time properties are called "traits".The is NAME (DATA) syntax defines traits on containers and subroutines, as part of their declaration:

constant $pi is Approximated = 3;   # variable $pi has Approximated trait

my $key is Persistent(:file<.key>);

sub fib is cached {...}

If you follow the idea that in Perl6 everything is an object, these traits at compile time modify a given instance. In the examples above the $pi instance of the constant class is modified to have a Approximated trait that is set to 3, the $key object is made persistent to a .key file, and the subroutine instance fib is given the cached trait for presumably memoization.

Synopsis 6 goes on to state:

Properties are predeclared as roles and implemented as mixins--see S12.

So at some level in Perl6 Traits are Roles that are applied to instances. This is the second point of confusion.

Finally in the evolution of Moose we, that is the people in #moose at the time, originally tended to only refer to Traits to Roles that applied to metaclass instances. Traits in this case were things like MooseX::Storage's 'DoNotSerialize'. This trait you can apply to a attribute and that attribute is skipped when MooseX::Storage does it's serialization routine. These traits are used all over, MooseX::POE is implemented as just such a trait. Mostly they do their work hidden in the Meta Object Protocol.

The logic behind calling these things Traits was two fold, one if you consider the concept of a trait from perl6 it is conceptually similar to a Role applied to an instance. and since Metaobjects in Moose are themselves just instances that define things like Classes, Attributes, Methods, and Roles the idea of a Role that applies instances being called a Trait is small step. At the time we didn't have a lot of places where people generally applied Roles to non-metaobjects instances. This was before MooseX::Traits was written, before MooseX::Object::Pluggable (the basis for Devel::REPLs plugin system), before a lot of things we have now.

So where do we stand now? We have this concept, "a composable unit of behavior", that has two names: Roles and Traits. Is this confusing? Yes, somewhat. It's messy and confusing to new people.1 Is it useful? yes, somewhat. Just like having multiple names for myself is useful to help differentiate context2, having different names for subtly different contexts is an "Advanced Feature". Like so much in Perl you can choose not to use it and refer to everything as a Role, or a Trait, or a "composable unit of behavior".

By: Chris Prather on 2010-08-11T00:00:00

Tags:

link

The Perl Foundation

Gabor Szabo recently asked on his blog what we want to see out of The Perl Foundation. This was in response to the issues raised in comments on his grant request. I'd made a comment in there that I figured I should pull some of ideas from my comments there out into a blog post in response Gabor's question.

Obviously much of the comments are specifically a response to the particular grant proposal. However there are important pieces in there about what I think the future of the TPF could be.

Workshops

The TPF current helps with much of the infrastructure and financial support for running the Three Perl Workshops in North America as well as YAPC::NA. I know this because I've been involved with organizing a workshop for the last 3 years (Frozen Perl initially and then Perl Oasis), as well as writing the winning bid for YAPC::NA 2011 from Dahut.pm and leading the organization efforts there1.

The conferences committee has put together excellent documentation for helping plan a workshop or YAPC. Depending on the level of commitment you want from them, they help process payments and write checks for the venues etc.

I would love to see them continue and expand on this process. This is an "easy win" for them because many workshops are self-funding. I would love to see those of us like Pittsburgh, Minneapolis and Orlando be called on to help give advice to new groups looking to host their own workshop or write a YAPC bid. I know I was actually moved by the amount of support I got at YAPC after the bid was announced from former organizers Dan Wright, Casey West, Heath Bair, and Rob Kinyon to name a few2. These conferences are a steal compared to the equivalent in other communities, anything we can do to make them bigger and better should be a priority.

One of the pain points of being a conference organizer is fund raising. Each set of organizers must individually contact all the different companies who may or may not sponsor and give them a pitch. This is not only highly inefficient, it annoys the companies that sponsor. I think that one possible thing that the Perl Foundation could take on here would be to take on some of this work. If we had someone at the TPF level who could contact a list of donors and help work out some basic sponsorship each year for the different workshops it would smooth the process unmeasurably. These donors would be sponsoring the workshops directly, that wouldn't change, but they would be coordinated across all of the events the TPF is responsible for so we can help balance funds and grow the number and quality of events.

Grants

The Perl Foundation currently issues grants quarterly. In fact the 2010 Q3 Call for Proposals was just announced. Grants are for $500 to $3000 in funding and help targeted projects get done. This is how the Moose documentation was written.

The TPF traditionally has had a poor record when it comes to grants. Looking at the grant history an embarassing number are failed. However they are increasing their success rate. Dave Rolsky has an excellent post discussing the nature of grants and motivation. Let's just say that for some people they can provide the proper incentive to perform good tasks for the community. Having them is in my mind a net benefit.

Events

Much more recently, and closer to the nature of Gabor's grant proposal are the TPF involvement in non-TPF events. These events aren't specifically non-Perl but are simply not one of the official events that the TPF helps sponsor. These would include OSCON as well as many of the events listed on the wiki. Gabor has been doing an amazingly good job of organizing people to attend these and help spread the Modern Perl movement beyond the echo chamber.

I personally think that the TPF should elevate this process to equal to the Conferences and Grants. Those two efforts have official committees and budgets to allocate to proposed efforts, and so should the Events group. The budget would go toward whatever is necessary to attend an event (SWAG, travel expenses, booth/space rental), and be allocated at the discretion of the committee.

Conclusion

As you can see the ideas here are a consolidation of the things the TPF are already doing. I think that right now the TPF needs to organize itself and find it's own identity and purpose. This is an introspective process fundamentally but can be done in consultation with the community3. Only once they are successful at the things they are currently doing will they be able to properly focus on a new endeavor.

By: Chris Prather on 2010-06-27T15:08:03

Tags:

link

"Patches Welcome" or Volunteers vs Hobbyists

There has been a strong meme going around that I've not been paying attention to until today. I'm not sure my opinion really matters here but I thought I'd add my perspective which doesn't seem to be represented well in the discussion.

I've been paid as a Perl developer for a little over a decade now. I've been involved in various degrees in the Perl Community for a little less than a decade. I have been what I consider actively involved in the Perl community for only about 3-4 years. In that time I've watched some projects I've been involved with flounder and effectively die, and other projects not. I've worked for very large companies with a DarkPAN problem, and for very small companies that contribute heavily to CPAN. I am currently running another.

All of this is background to say "I've been around the block a few times".

So the current "Patches Welcome" … discussion … seems to be based around the idea that CPAN contributors should treat their volunteer work as if it were equal to their day jobs. The analogy made is that of a volunteer Firefighter, or Nurse, or the extreme example the Peace Corps1.

I think the analogy to Volunteers like this breaks down. Those jobs are never treated as hobbies. A CTO I used to work for is a volunteer firefighter. He will never get a call and say "you know, I just ate a big plate of ribs, I'm gonna sit this one out". I'm sure if he did, the rest of the squad would say "Dude, don't come back." (If they didn't, I would have serious qualms about moving into that community).

Anything I've uploaded to CPAN that I wasn't directly paid to do was done because I love doing it, recreationally. It's a hobby. RelaxNG support for XML::Toolkit won't happen until I am in the mood. If you would like it to not be a hobby for me, I have an hourly rate that is I'm told very reasonable2. I hate saying that, but it's true.

As a hobby FOSS programming is a team sport. "Patches Welcome" is an invitation to play.

If you ran into Tony Hawk3 skating at the Brooklyn Banks, would you tell him his flip kick was a little off or ask him to help you with your pop shove-it? Yeah, me neither. But if we were to do so, and he replied "hey I'm busy right now, why don't you show me what you mean"? Even if he phrased it like "show it, hot shot" that shouldn't automatically translate to "screw you, I'm TONY HAWK!"; it's challenge to participate.

I've never skated in my life, but if a professional skateboarder4 offered to work with me if I were to show up and try. I would. If I can't or don't try to participate, does that reflect on them?

"Patches Welcome" is an invitation to play. It may be said during a period of frustration or exhaustion. It may be said to people who don't know the first thing about the game. It may even be said by people who mean to say "screw you, I'm STEVAN LITTLE!". That doesn't make it any less of an invitation.

I have already started discussing what we as a community can do about increasing the number of professional opportunities available5. If you want to discuss how people should be more Professional about their recreation, you really need to look at the definitions of those terms.

The thing of it is, discussing this is unprofessional. Claiming you know best what something someone else means is unprofessional. Claiming that your time (recreational or not) is somehow holy or too valuable to share is unprofessional. So let's move on and do something else with our time.

I'm not expecting to even be contacted by a professional skateboarder. I'm pretty sure ours is the only industry where not responding to complaints in a blog some where somehow makes us less professional too.

By: Chris Prather on 2010-05-20T19:08:24

Tags:

link

Vote Transparent

1

By: Chris Prather on 2010-05-20T01:21:00

Tags:

link

Fixing a Hole

Recently xenoterracide mentioned an issue he had with Dist::Zilla which he solved in a clever way1. I had been thinking about this problem for a while myself. RJBS generates solid code, and nobody agree's 100% on everything I respect him enough to give serious thought to his solutions to problems. So it was surprising to me that I had been looking at Dist::Zilla for a while and found something about it unnerving that I couldn't put my finger upon. Then shortly before xenoterracide's blog post I came to the same realization he had.

Dist::Zilla is designed to help the author develop faster, but it (inadvertently I'm sure) disenfranchises people who might contribute a patch by raising the bar for contribution. There are extra hoops you have to jump through to contribute. More modules from CPAN you need before you can work on the modules from CPAN you need.

We have this problem with Moose, even though it uses Module::Install. To hack on Moose you need roughly ten extra modules installed that aren't required to run Moose. That is assuming you want to properly test the results. I ran into this tonight when I was setting up a smoker for Moose. My smoker couldn't just checkout the git repo and start smoking it needed at the very least Module::Install and Module::Install::AuthorRequires.

The solution I found was to simply embrace the problem. Task::SDK::Moose is on it's way to CPAN. This is a module that will install all of the modules you need to hack on Moose or Class::MOP straight from the repository. To paraphrase Homer Simpson.

Here's to CPAN: the cause of and solution to all of Perl's problems.

I'd like to thank doy for vetting the modules I included and making sure Class::MOP was covered.

Update 2010-05-14

Talking with RJBS on IRC today, it was a carefully considered decision.

[A]ll of my dists can be tested with "prove -lr t" and I accept patches against the cpan tarball. [B]ut in the end, I decided that 99.9% of my code was written by me, and contributions were few and far between; making things much easier for me and somewhat harder for everyone else benefitted me

In no way did I wish to express that RJBS was being sloppy. He is an excellent developer, and I use more than a few of his modules every day. Dist::Zilla is part of Task::Kensho because I think it makes creating a distribution simpler; something we want more people to do.

By: Chris Prather on 2010-05-12T00:00:00

Tags:

link

With a Little Help From My Friends

So I haven't blogged much in the last month. Now I blog twice in one evening1. I've been incredibly busy on something that it turns out is the topic for this post.

Today coming across the Iron Man feed was Gábor Szabó's post about "Cooperation among Perl freelancers". This hit pretty close to home for me since last September or so I started working full time for my own company, which is at this stage operating as a small Perl consultancy.

I've spent the last six months (when I wasn't working on client code) learning as much as I could about freelancing, consulting, and running a business in general2. I can fully appreciate what Gábor is talking about when it comes to fluctuating demand. The problem of scalability he's pointing too happens to larger businesses as well as smaller ones. It seems that either you have too much work, or not enough, never in between.

One of the common refrains I heard at my last job was how hard it was to find good Perl talent, which always struck me as odd when I hear from people how hard it is to find a good Perl job. As a consultancy it seemed to me I would be in an ideal position to bridge that gap. I participate in the community, I (generally) know when what I consider good Perl talent is available. I've been lucky a few times and have been informed when a good Perl job is available, and have been able to match people up.

Often however the problem isn't that the talent and the jobs aren't available, it's that they're not available in the same place or at exactly the right times. One of Tamarou's contracts is with a company that for business reasons cannot hire telecommuters directly. We solve that problem for them. This is I believe what mst called a dev shop.

If you haven't already read mst's blog about it go do that now. I'll wait. Done? Did you read the post he linked to? No? Go read that too. Good. I've been reading and thinking about stuff like this for the last year3, and all of the stories are roughly the same. Hiring a freelancer or a consultant isn't easy. The rules are the same as hiring in house. They need to be high quality, professional, and a good fit with your company's goals and fill the places you're missing perfectly.

Not all consultancies are created equal either, Shadowcat are a very technically sophisticated company. They know Catalyst, DBIx::Class, and Perl intimately. At Tamarou we're focusing on embedding people to really learn your business domain. Different approaches because we're different companies, and you know what ... at some point I will say to a client of mine that we really need to hire Shadowcat to solve some problem we're having, I hope Shadowcat will do the same.

This is I think where the power of Gábor's idea is. Figuring out as a community where our skills lie, and helping each other find the best fit to solve our problems. We need to as a community talk about what we need and expect from each other and helping each other find the right fit. I'm not quite sure what form this should take, except I've recently started building a list of Dev Shops, Consultancies and Freelancers in the Perl space, I welcome people adding to the list.

By: Chris Prather on 2010-05-12T00:00:00

Tags:

link

iPad Hating has Jumped the Shark

In his recent post Wrong About the iPad, Tim Bray attempts to rebut a quote from Marc Benioff.

But then Benioff goes on to say “It’s not about text, or even animation, it’s about video.” That is so, so, wrong. Intelligence is a text-based application. Benioff isn’t stupid but that remark is.

I read Tim Bray because he is a well educated and interesting writer. Tim Bray isn't stupid, but that rebuttal is. I have a university degree in recorded intelligence (Technical Communication)1, one of the things my professors made abundantly clear was that intelligence is not bound to text. One professor in fact pointed out that at one point in time no less than Plato himself decried the growing reliance upon text as a substitute for Wisdom.

Socrates: I cannot help feeling, Phaedrus, that writing is
unfortunately like painting; for the creations of the painter have
the attitude of life, and yet if you ask them a question they
preserve a solemn silence. And the same may be said of speeches. You
would imagine that they had intelligence, but if you want to know
anything and put a question to one of them, the speaker always gives
one unvarying answer. And when they have been once written down they
are tumbled about anywhere among those who may or may not understand
them, and know not to whom they should reply, to whom not: and, if
they are maltreated or abused, they have no parent to protect them;
and they cannot protect or defend themselves. -- [Phaedrus][2]

This same professor went on to speak about how we were now moving toward a post-literate intelligence. That is that we have people who are functionally illiterate, but their intelligence and world view is shaped by media that is fundamentally textual. 90% of the video we watch is based upon text, that's why it's still called Screenwriting.

Tim Bray goes on to show that he's not anti-video.

Oh, and by the way, I consume a moderate amount of video, and I really like doing it on the 1080p LCD TV just the right distance in front of my comfy leather chair with the great footstool.

Congratulations, you have just proved you are a fogey2. This is the cultural equivalent of Monty Python's Four Yorkshiremen.

FIRST YORKSHIREMAN:
In them days we was glad to have the price of a cup o' tea.

SECOND YORKSHIREMAN:
A cup o' cold tea.

FOURTH YORKSHIREMAN:
Without milk or sugar.

THIRD YORKSHIREMAN:
Or tea.

FIRST YORKSHIREMAN:
In a cracked cup, an' all.

FOURTH YORKSHIREMAN:
Oh, we never had a cup. We used to have to drink out of a rolled up
newspaper.

SECOND YORKSHIREMAN:
The best we could manage was to suck on a piece of damp cloth.

THIRD YORKSHIREMAN:
But you know, we were happy in those days, though we were poor.

Simply put Mr. Bray, You're not getting it.

My younger brother, although well past the age you could call him the "next generation", tends to prefer Hulu to his Television. Hulu has that special feature that it's not grounded in a specific time and location, unlike say Cable Television. Also we've been hearing for years how YouTube has spawned a bi-directional communication culture. People making and responding to dorky videos. Tim Bray has even commented on this several times over the years3.

This is what I think of when people tell me that the future is video. People who are now in their teens and pre-teens shooting video of themselves and uploading it to YouTube, because it's faster than blogging.

For disclosure I have pre-ordered a 3G iPad. I hope it will fill a sweet spot I found lacking in a hacker's device. I sound like a typical Apple Fanatic; I have a Macbook Pro as my primary computer and an iPhone as my "mobile device". Previous to both of these devices I used "Open" platforms (Gentoo and an Android powered G1 respectively), and found them both to be wonderful when I wanted to play with them, and painful when I wanted to play with anything else4.

While I have professional interest in writing applications for the iPad itself5, I have no time or energy to do so for recreational purposes. My recreational time is taken up working on things that do not live on my device, but rather by things that live on CPAN and the Web. While I would be happy if Apple were to decide to open their platform in the way that say Alex Payne recently outlined, I fundamentally don't care. My phone, computer, and eventually iPad, are the tools I use to get to the real place I do my work. The Web.

The arguments against the iPad are that because it's not Open means that somehow my use case is not possible, or that somehow my use case is somehow inferior to that of someone wanting to write applications that run on the iPad. This is I think where the true irony sets in. The arguments that Plato has Socrates make in the Phaedrus echo these same arguments. They are in fact the same arguments made against any technology that claims it will change the world. The fact that Mr. Bray has come full circle from Plato and argues that intelligence is fundementally textual highlights how silly things have gotten.

So Mr. Bray, I have to disagree with you that intelligence is fundamentally text based. I do this ironically because my rebuttal is textual, but titled with a reference to a visual common history.

By: Chris Prather on 2010-04-06T00:00:00

Tags:

link

No Vendors?

Recently in a post about his moving to Google, Tim Bray said:

The big thing about the Web isn’t the technology, it’s that it’s the first-ever platform without a vendor (credit for first pointing this out goes to Dave Winer).

I've always respected Mr. Bray, I follow his blog avidly and I really enjoyed his discussion of learning the Android platform and his Wide Finder project. While I may think that his Ruby fanboy-isim is a bit over the top, I'm unabashedly in love with Modern Perl so who am I to really talk?

This comment though, about the web having no vendor's. I think the point he was trying to make is that Tim Berners-Lee released the technology for the web to the public domain (not GPL, MIT, Artistc or any other licese but Public Domain) and thus anybody and everybody is free to implement the specifications without fear that someone will come along and require a license fee.

However that's not the only thing a Vendor does. A vendor supplies a technology or tool, documentation for using that tool, and support for when bugs are found in that tool. The "Web" in Mr. Bray's view may only be HTTP, HTML, and the related W3C specifications, but ultimately it's much more than that. The web has mutated over the last two decades. Today it isn't just HTTP and HTML, it's also FBML, and REST Apis, and Twitter.

This brings me to the recent post by John Napiorkowski, a fellow Perl programmer and Moose developer. John pointed out that the Google Adwords API is introducing backwards incompatible changes, and that the current Perl API is going to be broken by these changes. This is exactly Google acting as a Vendor for a SaaS product, one that many people rely upon for income.

Google's official statement regarding support for the Perl API?

We recommend that developers either migrate their applications to another language and client library (such as PHP, Python, etc.) or
continue the development of their own implementation in Perl.

That's google acting like a crappy vendor. This recommendation is an insult to your customers. Google is saying that it would be easier if people spent the next month re-writing what may be a core portion of their business (and if you're using adwords is not not a core part of your business?) in a brand new language, rather than depend upon Google to care enough to bring one of their vendor supplied libraries up to date.

Now in Google's defense they prefaced that recommendation with:

We are aware that the Perl client library is out of date, and we are actively working on updating it to take full advantage of the v200909 version of the API. We encourage AdWords API Perl developers to contribute to the open source project and help to accelerate the process, but we want you to understand that this work will not be completed prior to the April 22 sunset of most v13 services.

Thank you Google for saying that even though you don't care enough about Perl to support your paying customers you care enough about open source to let those same customers do the work themselves. This is a step forward from the way things were in my Mom's day.

Google may not be evil, but they're certainly being crappy.

By: Chris Prather on 2010-03-17T00:00:00

Tags:

link

Been There, Done That

An email recently came up on the EPO-Marketing list that I made a long and rambling reply to. The ideas I expressed there I think are important and should get expressed to a larger audience so I thought I'd put them here.

The original poster to the email mentioned the recent excursion to CeBit. The impression was that the current marketing efforts while enthusiastic lack an articulate and compelling story for Perl as a solution, and tended to focus on specific Projects, specifically the vanguard projects of Catalyst, Moose, DBIx::Class, and Padre.

I agree. I think the problem is that we as a community, or the limited Modern Perl community, or even the few people with ideas and loud mouths, haven't really had the discussions about "next steps" in articulating the Modern Perl Story. We have still been dealing with the internal process of getting the the community to embrace Modern Enlightened Perl, and the need to promote Perl in general.

So now we need to tell the Modern Perl Story for people who aren't inside the echo chamber.

Moose, Catalyst, DBIx::Class, and Padre show large popular projects written in a Modern Enlightened style. A style that perhaps needs some articulation. From my perspective it is that they leverage Perl's cultural strengths: flexibility, distributed development, and strong conventions.

Flexibility in that they embrace TIMTOWTDI allowing you to customize and override, they choose configuration over convention at the code level. All three of these packages reflect this in the sheer number of their extensions. Catalyst::Plugin, MooseX, and DBIx::Class as top level namespaces all have dozens and dozens of modules under them above and beyond the core projects.

For distributed development not only do these projects have an open commit policy, anybody who shows up with a patch generally can get a commit bit, they also utilize the infrastructure CPAN brings to the table. They prefer to utilize CPAN dependencies over re-writing code when it makes sense, taking advantage of the 20,000+ packages in this 15 year old globally distributed environment. They also have very large test suites, and responsive core maintainers who watch the automatic testing that the CPAN Testers provide across at last count 58 different platforms.

Finally with strong conventions let me focus on the project I know the best of these three, Moose. Moose has worked hard over the last four years to build out more support for authors of patches. We have a documented support policy, a committers guide, and several author-specific tests that include code style, documentation, and optionally testing all down stream dependencies. We do this because, although we document that we priorities correct behavior over everything including backwards compatibility, our social conventions are to try maintaing compatibility where possible. We have our own best practices and idioms, and have had several long discussions about where things should be enforced via warnings and exceptions, and where we should leave them at the discretion of the author. Obviously we are not perfect at this, but we make the attempt and that in my biased opinion counts for a lot.

These three factors are not unique to these projects, they are instead the ideals that the community who surrounds these projects strive for. They are, in my opinion, the ideals that the Modern Enlightened Community strives for.

There has been no formal research into why developers who have tried Perl choose another language. I'm not a social scientist, I have no clue how to begin such a project. I would love to have some research here. We can only speculate based on the comments we have all seen on various comment boards and have heard from co-workers and friends. On the other hand the largest reason I've heard for people who stay with the Perl community vs other communities is culture. This is articulated best in Piers Cawley's recent blog post Falling out of love with a language, where he talks about going from Perl to Ruby and back. I'll let you read his excellent essay on it.

One of the things I've noticed in these discussions about Perl marketing is that we have unconsciously embraced the idea that Perl is losing ground somehow. I have held this idea too, at times. Recently however I've come to suspect that this isn't (yet) the case.

This came up recently when Rob Diana posted Web 2.0 Programming Language Job Trends – February 2010 to his Regular Geek blog. It was mentioned on twitter and when I looked at it I wondered why Perl wasn't included in the Web 2.0 languages. The reason is that Rob included Perl in the earlier Traditional Programming Language Job Trends – February 2010.

When you add Perl to the first chart, it really stands out in comparison to most of the "Web 2.0" languages. In fact it's comparable only to Javascript in the chart, as you can see below.

But when you add Javascript to the Traditional Languages chart1 you see it fits in nicely with those languages.

I'm not sure what the implications of this are, except that the Perl and Javascript seem to trend closer to C# and C++ than they do Ruby and Python in the Job Market. This probably has some bearing upon how these languages are used in the market place and who our actual customers and competition are. What is certainly true here is that we're not in anyway really losing ground to anyone, yet.

Ultimately the real power of Perl isn't that we can implement any given solution better than another language. The real power is the cultural artifacts we express in the vanguard Modern Perl projects. It's that we allow configuration over convention at the code level, and that we are developing tools for enforcing cultural consistency. The biggest winner is that the odds are any given solution is already implemented and sitting on CPAN ready to be used. A real comparison between Modern Perl and any other language is is "write these dozen lines in your language" vs "Search search.cpan.org for someone else's solution".

Modern Perl's internal slogan has been TIMTOWTDI BSCINABTE (There is More than One Way to Do It. But Sometimes Consistency is Not a Bad Thing Either). I think if I were to suggest a slogan that Perl should have in the larger market place it's BTDT-IPAOC (Been There, Done That - It's Probably Already on CPAN).

By: Chris Prather on 2010-03-14T00:00:00

Tags:

link

Brewing Up a Storm

Because I recently had the opportunity to do a fresh re-install of my world1, I've spent the last few days playing with App::perlbrew. App::perlbrew is the invention of Kang-min Liu aka gugod, and the basic idea is that it's a perl manager. It will install and track several different installations of Perl for you, allowing you to switch between them at will.

$perlbrew installed
perl-5.10.1
perl-5.8.9
perl-5.6.2

$perlbrew switch perl-5.10.1
$perl -v
This is perl, v5.10.1 (*) built for darwin-2level

I'd like to state now that what gugod had was very nice. It was very simple, very straight forward and did exactly what it said on the package. I have not spoke with him about this application, and anything I say here is my opinion and has no reflection upon him or anybody else that might have been involved.

Having seen what power some simple scripting can do in the form of Miyagawa's App::cpanminus, I started tinkering with perlbrew. It started with perl 5.10.1 not installing properly on Snow Leopard2, so the first thing I added was a way to force install.

perlbrew install -f perl-5.10.1

Then I decided it and local::lib both sharing $HOME/perl5 wasn't going to be pretty. So I taught it to use an environment variable PERLBREW_ROOT to relocate the default install. In my setup I have it set to $HOME/.perlbrew.

$export PERLBREW_ROOT=$HOME/.perlbrew
$perlbrew init
Attempting to create directory /Users/perigrin/.perlbrew/perls/current
Perlbrew environmet Initiated.
Required directories are created under /Users/perigrin/.perlbrew.
Please add this to the end of your ~/.bashrc:
    source /Users/perigrin/.perlbrew/etc/bashrc

Then I got annoyed with the pages of verbose output, so I stole a page from cpanminus and implemented a quiet switch that is enabled by default. Output now goes to $PERLBREW_ROOT/build.log.

Today I integrated it with local::lib so that if you have local::lib installed it will drop the proper configuration in the perlbrew configuration scripts so that when you install new modules they get installed into your perlbrew managed directories3.

Finally just now I finished getting --as= working. This means that if you build a custom perl you can have it installed under a special name and then easily switch to and from it. I'm planning on using this to build a --as-workperl that contains all the modules I need for work.

$perlbrew install perl-5.10.1 --as=debugging-perl -D=debugging

I would like to integrate a plugin system4, but all in all I'm very happy with it. Much thanks to gugod for making it to start with, and to Miyagawa for getting me itching for small lightweight tools in my toolchain. If you're interested in my changes, you can check them out on my github

By: Chris Prather on 2010-03-07T00:00:00

Tags:

link

Why I should (apparently) be shot on sight

Recently chromatic posted:

[12:52] chromatic: More and more I think Module::Install hurts CPAN's installation experience. Ia! Ia! EUMM fhtagn!

Which I found curious. I suspect it is because it resorts to driving ExtUtils::MakeMaker which chromatic has been vocal about hating in the past. It was however Elliot Shank's comments in response that I found really off putting.

[12:58] clonezone: .@chromatic_x I want to throttle all CPAN authors that use Module::Install. M::I may be great for the author, but it sucks as a user.

[12:59] clonezone: Any CPAN author that uses Module::AutoInstall should be shot on sight.

Needless to say I use both Module::Install and Module::AutoInstall, and before the firing squad shows up to execute my unrepentant self I figured I should explain for posterity's sake.

First some history. In 2003 I became interested in the OpenGuides project. OpenGuides is a Perl based wiki to build guidebook style websites for Cities. I maintained a guide or two for a while before losing the time and resources to host them.

OpenGuides uses Module::Build. Early on when I was starting to work with OpenGuides as a Guide Admin, a troublesome build of Module::Build had gotten into CPAN. I don't recall the details and to be honest they're not important. Things happen, not every release can be perfect. This build basically caused a ton of pain for anything that used Module::Build for installation.

Obviously Module::Build has fixed these problems since then. I have not had a problem in over five years with Module::Build. Most of the time I don't recognize that it is even being used1. This story isn't about Module::Build, it's about why I deserve to be shot on sight.

The experience left a bad taste in my mouth. One bad module could break my entire toolchain. A module that the maintainers of OpenGuides didn't control and couldn't fix for me the user. That was a horrible experience, and it came right as I was starting to release my first Perl modules onto CPAN.

I am lazy, and at the time I was using Module::Starter to build my distributions. Module::Starter would build my Makefile.PL to use EUMM and everything generally "just worked", but I still didn't like the fact that I had to rely upon the user having the right toolchain installed. When someone, I suspect mst suggested I take a look at Module::Install because it auto bundled itself into inc/. I was curious enough to take a look. The declarative sugar was nice, but the bundling was the important part.

Now there has been an ages old debate about bundling. Adam Kennedy explained it well enough

In the Module::Install model, all authors need to do incremental releases of the modules affected by the problem, but users need to do nothing.

In the Module::Build model, all users affected by the problem need to upgrade their version of Module::Build, but authors need to do nothing.

At present, both of these don't solve this problem correctly.

Module::Install doesn't have a method for ensuring authors upgrade, and Module::Build doesn't have a method for ensuring users upgrade.

I quite obviously lean strongly on the "make the author responsible" side of the fence. The number of Authors of CPAN modules is smaller than the number of Users of CPAN modules. Make the pain point as small as possible is my argument. Module::Build even supports bundling itself now as well. So this story isn't really about bundling either, this story is about why I deserve to be shot on sight.

When one starts using Module::Install one quickly finds Module::AutoInstall, the one that has the firing squad after me. Module::AutoInstall will spawn a CPAN/CPANPLUS instance to chase down dependencies2. We use this at one of my jobs to maintain our dependencies for the very large application we're maintaining, but it's a feature that CPAN and CPANPLUS both have managed to do for quite some time now.

The other feature that Module::AutoInstall performs, the one I'm willing to be shot for, is Features. Features are what make utilities like Task::Kensho, Task::Catalyst, and Task::Moose useful. They allow you to gather, possibly optional, dependencies together into smaller groups and present that as a choice to the user. Features do not exist in ExtUtils::MakeMaker, and in Module::Build the closest I could find was a "reccomends" dependency which lacks the grouping (as far as I could tell from the documentation).

I have three modules that require Features to properly work. Task::Kensho and JSON::Any are the best known of them. Without Module::AutoInstall these two modules would be a much bigger hassle for my users. JSON::Any for example would require me to define a specific default JSON package and make the others "reccomended", this rather defeats the entire purpose of JSON::Any. As for Task::Kensho, one of the things I like most about it is that beyond a certain set of core modules relating to the tool chain and testing, everything else is optional. This means if you don't want or need POE on your machine (perhaps because you enjoy AnyEvent), Task::Kensho doesn't force you to take it. But it does so at a large enough level that if you opt into POE, you get a good set of recommended modules picked by default.

I am also lazy, I mentioned this. I have several Modules that need to be updated to no longer include auto_install because they don't need or use Features. But despite at least one of these modules being popular enough to make a Top 100 list, I have never had a complaint about not being able to install it. I cannot repent for thinking about my users3. So I will clean up the modules I have that don't require Module::AutoInstall while I wait for the firing squad for the few modules that must have it so that the user experience is the nicest I can provide.

By: Chris Prather on 2010-02-18T03:42:00

Tags:

link