The Room
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. Is it useful? yes,
somewhat. Just like having multiple names for myself is useful to help
differentiate context, 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 there.
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
few. 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
community. 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 Corps.
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 reasonable. 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 Hawk 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 skateboarder
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 available.
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
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 way. 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
evening. 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 general. 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 year, 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), 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 fogey. 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 years.
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 else.
While I have professional interest in writing applications for the iPad
itself, 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 chart 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 world, 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 Leopard, 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 directories.
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 system, 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 used. 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 dependencies. 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 users. 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