6 posts tagged “advocacy”

Recently with all the renewed effort on the part of Perl programmers to be better public advocates of our language, I've noticed an uptick in counter productive and quick frankly hateful comments directed at Perl.

I'd really like to find out why.  I'd also like to be reasonable and think there's actually something rational behind all this.  Several ideas come to mind.  For example, is all this negativity based on Perl's perception as spagetti code?  Is that just rumor or have many of you out there been required to step in and take over projects with difficult codebases?  Is it due to the fact that Perl 6 is still in development?  Has it to do with something many of you have experienced on the job?  Or maybe you've tried to get help from various Perl communities and gotten flamed?

I really have trouble understanding where this is coming from.  Personally, I use Perl because I find it works with my brain and not against it.  I've not found this to be the case with PHP, Python or Ruby.  I have nothing against any of those languages, but it makes little sense for me to force myself to relearn and rebuild my current skillset in a different language that doesn't really offer me a compelling reason to do so.  I'm deeply invested into the Perl community as a contributer to several important open source projects and that's what I enjoy about my job.

However the negativity is something I'd like to address if possible, because all this hate directed at Perl can affect me personally in terms of future employment and job options.  This directly affects my family, my wife, son and dog, so I take it very seriously. 

Because to be quite honest, the combined popularity of the most common scripting languages doesn't come close to countering the Java/C# juggernaut, and as someone committed to open source / free software this is an additional worry for me.  Neither of those languages are particularly committed to software freedom.  As far as I am concerned Sun (or Oracle now I guess) and Microsoft give some lip service to software freedom since that's a popular thing nowadays, but it's minimal and tactical in nature.  Free free to argue with me if you think I'm wrong, but I just don't see a deep and fundamental commitment.  Now, maybe you don't care about software freedom, but I'm old enough to remember the days when being a programmer nearly always involved proprietary tool chains and expensive certifications.  If it wasn't for the threat posed by developers and advocates of free software there would be no Java Community Process, no Mono, nor would there likely be quality free version of IDEs like NetBeans, Eclipse or the various free 'Express' versions from Microsoft.  There would be no free, online versions of documentation.  So it really seems to be we should be working together, not against each other. 

Several possible points of collaboration that suggest themselves would be standards for testing, deployment and management of applications.  Also, we often depend on a core set of external libraries, such as MemcacheD, xml and xslt parsing libraries and so forth.  It would be great if we worked together to improve these and to ensure that the language bindings were of consistent and high quality.

Each of our communities has different strengths and weaknesses.  The Rails group are great at advocacy and Ruby has a reputation for delivering nice, clean code.  Python really focuses well on education and ramping up newcomers.  Perl has great testing and deployment tools, as well as CPAN.  Why are sniping each other when working together would have so many benefits?

10. It's Getting Great Press!

I can't remember the last time a Perl module has generated so much discussion, whether in blogs, at conferences or just in general.  People who use it nearly always become advocates.  Here's a few I was reading just recently:

• http://blog.jrock.us/articles/Myth:%20Moose%20is%20an%20unnecessary%20dependency.pod
• http://avatraxiom.livejournal.com/70947.html
• http://transfixedbutnotdead.com/2008/03/12/doodling-with-moose-part-1/

You would not have to look hard to find many, many more.

9.  Makes Creating Objects Fast an Easy!

Whether you are using 'classic' Moose or playing with the new MooseX::Declare I have never used an object system that was so easy and felt like it belonged to Perl.  In the best tradition of Perl it makes easy things easy to do, and make the impossible doable.  All this with minimal boilerplate.

Not convinced?  Check out this comparison of all the stuff you need to write to make a non Moose Perl object approach the functionality of what you get out of the box with Moose.

8.  Makes Perl Objects Powerful!

Moose is built on top of a well researched and highly respected Meta Object Protocol which means Moose objects and the framework and software ecosystem being built around it are on very firm foundations.  We've been developing on and in Moose for more than three years now and the concepts underlying it are not showing signs of weakness.  Usually by now people would be talking of a 'rewrite to get it right' but clearly Moose is pretty right as it is.  As a result we can focus our attention on expanding MooseX modules and on advocacy and documentation.  Clearly, Moose is the most powerful object system for Perl and is a heavyweight in comparison to other languages with strong object oriented features.

7.  Moose Attributes

Removing all the boilerplate associated with creating object attribute reader/writer methods, as well as making it easy to apply type constraints (see for more) was probably the thing that got me interested in Moose to begin with.  If Moose only did this, it would still be useful.  That fact that this feature is just a small one among many is mind blowing.

6.  Moose Baked in Type Constraints and Coercions

Although I've always loved that Perl is a dynamic language, I've often wished it was easier to validate arguments and attributes.  There's probably been a dozen or more such systems on CPAN, but Moose Type Constraints mixes the perfect blend of usefulness and wide adoption that met my immediate need while growing with me as a developer.  Now I'm a Type Constraint junkie, who spends him time researching more and more esoteric type constraint concepts. 

5.  Moose Roles are Awesome!

I could say more, but someone smarter has recently done a blog series about Moose Roles that I highly recommend you check out.

4.  MooseX

Do a search for "MooseX" on CPAN (here for example) and you are going to get a ton of useful things.  This points out not only the energy and excitement of the community, but serves as more proof that Moose was 'done right' the first time.  the For a list of recommended MooseX modules see this article.

3.  Great Moose Inspired Stuff!

There's more and more stuff showing up on CPAN that is Moose inspired.  For example, the recent Catalyst port has revitalized development on this important web application project.  Or check out KiokuDB if you are looking for a fast and easy way to persistent your objects.  If you are interested in a cutting edge user interface and interface modeling system, see Reaction.  I've only scratched the surface here.

2.  Documentation, Tests and Online Tutorials.

When I got to Moose, I found there was not only reasonable documentation to help with with the basics, but also a straightforward tutorial that showed how to go about building applications the Moose way.  It definitely helped me to grasp the essential bits and it got me started very quickly on the features I found most useful and time saving.  For me this was the key to adopting Moose and the online docs really show you the heavy benefits right off the top.

When I needed more examples, I could go straight to the test directory and find scores of useful tests that showed how the system worked as well as provided me very useful code samples.

And the Number One Great Thing about Moose...

1. The Community! 

Not only would all the above not be possible without the tireless and creative effort of the group of core developers, but this community has really reached out and brought lots of people into the fold.  They are greatly responsive to bug reports and feature requests, maintaining a pace of releases that is truly amazing.  This community also has some of the smartest people I've ever had the pleasure to work with.  I definitely feel being part of the Moose community has not only made me a better programmer, but a better person as well.

• Mailing List Info
• IRC Chats (Join Channel #moose on irc.perl.org)
  

One of the more satisfying things to happen to me lately on the work / career side of life has been how I've been able to see the impact of my open source contributions on the community as a whole.  For the small bits here and there, such as the support for MySQL native replication I started working on last year, or work related to MooseX::Types and MooseX::Types::Structured, I can actually see that others are not only using the code, but actually working on it with me to solve bugs and add features.  It's an amazing feeling to feel part of this grand, distributed tribe of interested Perl programmers, and it's even more amazing, and humbling, to feel like something I did is actually out there making another's life easier.

So, if you are just starting out with bug patches, documentation fixes and tests for edge cases, I encourage you to stay with it.  Although those things may not have so much visibility, they are very important and will eventually lead you, as your skill and abilities improve, to making even more impact on the community.

Which leads me to the second part of my mediation, related to something that got screamed at me while I was heading for my subway car (I work in New York City).  There was a man who was preaching to the crowd, and his topic was salvation and how to get it.  He was asserting that no one person is intelligent, wise or capable enough to discover and achieve salvation independently.  Leaving aside religious beliefs for the moment, what the man said reminded me of how one boss I had once spoke lovingly of the 'shelf of common components' his IT had developed over the years.  This was a powerful intellectual asset.  However when I got access to the CVS repository, what I found was a pile of code, written against a 5 year old version of Java struts, without documentation, unit tests or examples.  Also, the original authors were no longer with the company.  Which to me proves a point: There are very few companies (if any) with the internal ability and IT capacity to create, maintain and properly document most of the types of common framework components we as developers need to do our jobs.  Open Source code, if it's a living project, gets tossed around the Brownian motion machine of the community, which keeps it fresh and mutates it so that it stays in the now.

What I've said has been said before, but I never really realized it in quite this way.  It's not just about many eyeballs making all bugs shallow.  It more about the diversity of backgrounds and needs those eyeballs bring.  It's about how code dwindles when it's stuck in isolate, and how code loses it's way when it experiences sensory deprivation. 

This mediation was removed from part two of the BlueChild project.  Part two deals primarily with ways to setup your development instance, which obviously will revolve to a large degree around CPAN.  Originally meant as a discussion about how CPAN shares merit and responsibility, I decided to remove it since it felt a bit too tangential, as well as lengthened what was already a long blog posting.

I've come to strongly feel that a key difference between Perl and other languages is the depth to which you need to engage the Perl programming community in order to progress in skill and make best use of the available resources.  I am not saying other languages don't also have large communities or engage in community building.  However, Perl as a language seems to be to be more shaped by the community and the push and pull of ideas batted about the mailing lists and on IRC chat rooms than most other programming languages.  Partially this is due to the fact Perl does not have one single company behind it with particular vested interests in promoting and shaping it.  This is combined with the distributed and anarchistic nature of CPAN development to promote a culture that is extremely merit based (you get help and respect first by the nature of your contributions to the community) and yet insists on sharing responsibility for many key projects as widely as possible.  This is achieved first by the ease at which it is to contribute code via shared software version control systems and by how widely co-maintenance of those modules as published to CPAN are.

On CPAN, it's normal for “handoffs” to take place over the maintenance of important modules.  This distributed style encourages the development of sustainable and useful bits of code that can be glued together to form more complex systems.  This is one of the key differences with Perl.  Many other languages have distributed systems similar to CPAN, but they tend to be based as plugins around existing large projects.  Perl tends to follow the Unix approach, where each module is intended to do one and only one thing as well as possible.  Although this requires more upfront effort on the part of developers to learn the tools, it results in greater flexibility.

Since you have a big investment in so many of these shared resources, it encourages people to reach out to the primary authors of important projects.  You might have a bug report, and hopefully a test and maybe offer a patch to fix the issue.  I see a lot of this type of shared responsibility.  For example, one developer might take the lead in releasing a new CPAN module during the first few releases (thus shaping the overall contours of the module) and then grant co maintenance to one or more important users of that module.  Or, you might assign the job of release manager to someone you, as the lead, is trying to help mentor.  In any case, this kind of responsibility sharing, via CPAN and increasingly via source code control systems such as git and github is a means by which the community shares merit and grows talent.

Being so, you really need to track what's going on in the community, and participating to the degree you are able.  I recommend you do at least the following:

Following trends and updates to CPAN.  I subscribe to a syndication feed and check it daily at the minimum.  After a while you will get to learn which projects are being aggressively worked on.  Hopefully you will see a few useful things you didn't know about.  For example, I discovered Moose because it's a project with a lot of development and it kept showing up in my feed.

For the projects important to you, join the mailing lists or IRC chats where developers and user hang out.  I recommend 'lurking' a bit to get to know who is who and to get a feel for the tone of the group.  If you haven't been on IRC before, there's a great and easy to use Firefox extension called “Chatzilla” which although not the most feature-full IRC client, will help you get going.

For help getting to know Perl IRC channels.

There's a couple of blog aggregators you should know about:

planet Perl
planet Catalyst
planet Iron Man

I probably missed a bunch, feel free to add in the comments.

One thing I'd like to add.  CPAN get's a lot of flack at times when it's difficult to build your software due to changes somewhere in the dependency stack.  This used to frustrate me as well, but now I have come to understand that with a system as large and complex as this, keeping it working is work and not always easy work.  CPAN can be great when everyone takes responsibility for the bits they need.  I think the biggest issue is getting out all the information and tools needed to make it much easier for people to join and and solve problems on CPAN.  We need to make it easier to work with the source code (via something like git's easy cloning feature) and easy to find original authors and get co maintainance roles.  We also need to do a better job of teaching people how to become CPAN authors and get contributing.  I think if we can do that, CPAN will become as reliable as it is deep in features.

All the bits are in place and I could really use some help getting notice for the Catalyst 5.8 Press Release so please submit it widely and add it to your http://delicious.com/ bookmarks or whatever other social bookmarking you are using.  Let's try to get some press for all our hard work.

So far It's gone to:

use perl (pending)
slashdot (pending)
digg (http://digg.com/programming/Perl_Catalyst_Web_Application_Framework_Version_5_8_Release)
reddit (http://www.reddit.com/r/programming/comments/8h511/perl_catalyst_web_application_framework_version/)
ycombinator (http://news.ycombinator.com/item?id=589095)

I'll update this as I get more accepts.