Perl Oasis 2010 Thank You

So Perl Oasis 2010 is now done, I'm currently sitting in the Hackathon room watching people quietly mingle and work on their projects. All told we had 33 people from 15 PMs across 4 countries. This is a larger attendance than last year, but still small enough I felt I got to sit and talk with people and really hang out.

To forestall questions, yes video was shot of all of the sessions. I'm unsure of how long the editing process will take, but expect an announcement when the video will be ready. The quality of all of the talks was excellent and overall The general comments I got were very favorable, things like "excellent workshop", "well organized". So I'm pleased with the results.

On to the Thank You notes.

I want to thank the people who came, these conferences simply wouldn't work if nobody wanted to attend. I also want to thank the speakers1, nobody would want to attend if we didn't have such an excellent selection of talks. They were the show.

I want to thank Marty and Karen Pauly who traveled the furthest to be there. They are 2/3rds of the reason why Shibuya.pm was tied for the largest attending PM group. Karen also let Jamie and I talk her ear off with our organizing nattering and worries about the TPF.

I want to thank Mark Keating (mdk) for his excellent keynote on "The awful things we all must do and the most disgusting word you'll hear". He encourages all of us to step out and talk about Perl not in divisive terms (Perl5 vs. Perl6; Perl vs. Python, Ruby, PHP; Perl5 Version 10 vs. Perl 5.10) but rather to use inclusive terms (Rakudo and Moose and possibly Perl "Vincent"). Mark also presented me with our new mascot for Perl Oasis, Aurelia the Camel.

I want to thank DataRocket Data Services, who provided our A/V equipment. They are an excellent bunch of guys who do insane things with MySQL and very large data sets.

I want to specifically thank Cory Watson (gphat) and Magazines.com for stepping up and sponsoring the entire event. Without them we would be sitting in a parking lot somewhere, probably in the rain.

Finally I would like to thank my wife, Jamie, who the attendees all know worked her ass off organizing. I am an incredibly disorganized person and without her nothing would ever have gotten done.

We have already started talking with the venue about next year's conference which will be the 15th of January, 2011. I hope to see you then!

By: Chris Prather on 2010-01-17T14:22:00

Tags:

link

Starting Out with OOD

The basic question1 for Object Oriented Design is

For a given domain, how do you break the model up into Objects and Classes?"

Let's say we're going to build an application to model the life cycle of a Book. The naive approach is to start asking "What different things are involved with Books, and how are they related?" The domain can be literally infinite when you start breaking it out and exploring it in detail.

This ability to break things up is part of the power of Object Oriented Design, because it seems like it should operate the way people have thought about the world for centuries. For the most part it does operate that way. Without constraint, however, you end up lost trying to achieve some platonic ideal (like the questioner on Stack Overflow) or you end up with what people have come to call Ravioli Code.

The platonic ideal trap is trying to figure out if a Book has an Author or a Author has a Book, and what to properly name the parent class of Books, Graphic Novels, and Magazines. It's involved with questions of should a Magazine have a "Table of Contents", Index, or Appendices? Should a Graphic Novel? Trying to sort these things out is a fool's errand of fiddling details that may have no reflection on the needs of the system you're building. If the cover_style attribute is never called, does it matter that it might possibly return 'hardback' for a Magazine?

The other end of the spectrum is Ravioli Code. Ravioli Code is what you get when you no-longer model discrete components in your logic, but rather model sub-components. It's like talking about a Book not as a collection of pages, words and phrases but rather as a sequence of glyphs and wood pulp recipes. The resolution of the focus of your model is too tight, not only can you not see the forrest for the trees, you can't see the tree for the wood grain.

The Power of object oriented modeling needs to be constrained by the needs of the application you're building. Say for example you're building a system for tracking a single book that is being written without considering it's publishing or distribution. In this system you won't need to model Sales, Stores, Advertising or any number of things dealing with the distribution chain, nor would you need to know about paper bond, binding type, covers, type faces, line height or the minutia of building the artifact that is a Book. You will however need to model things like Pages, Chapters, Paragraphs.

To bring this back around to the point, in any application of Object Oriented Design the goal is to have a Class or Object hierarchy that matches exactly as much of "reality" as you need to accurately describe and solve the problems you're writing a program to solve, and nothing more. There is a quote by Antoine de Saint-Exupery2:

Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.

Instead of starting with "What different things are involved with Books, and how are they related?" we with really should start with "what features of a Book do I need to enable my application to deal with?"

By: Chris Prather on 2009-12-31T19:21:00

Tags:

link

A Little Bit of History

I recently did some digging for what may be some future writings, as well as possibly something larger. Part of those diggings involved research into Object Oriented programming's history. I found this example on wikipedia of Simula 67, the first Object Oriented programming language.

Begin
   Class Glyph;
      Virtual: Procedure print Is Procedure print;;
   Begin
   End;

   Glyph Class Char (c);
      Character c;
   Begin
      Procedure print;
        OutChar(c);
   End;

   Glyph Class Line (elements);
      Ref (Glyph) Array elements;
   Begin
      Procedure print;
      Begin
         Integer i;
         For i:= 1 Step 1 Until UpperBound (elements, 1) Do
            elements (i).print;
         OutImage;
      End;
   End;

   Ref (Glyph) rg;
   Ref (Glyph) Array rgs (1 : 4);

   ! Main program;
   rgs (1):- New Char ('A');
   rgs (2):- New Char ('b');
   rgs (3):- New Char ('b');
   rgs (4):- New Char ('a');
   rg:- New Line (rgs);
   rg.print;
End;

Here is a translation of the Simula 67 Example using MooseX::Declare

{
    use MooseX::Declare;

    class Glyph {
        sub print { confess “Virtual” }
    }

    class Char extends Glyph {
        has char => ( isa => ‘Charecter’, is => ‘ro’ );
        method print { CORE::print $self->char }
    }

    class Line extends Glyph {
        has elements => ( isa => ‘ArrayRef[Glyph]’, is => ‘ro’ );
        method print { $_->print for @{ $self->elements } }
    }

    # Main program
    my @rgs = map { Char->new(char=>$_) } qw(A b b a);
    my $rg = Line->new(elements => \@rgs);
    $rg->print;
}

There really isn't a point to this post, but I thought it was neat to see how nicely clean Object Oriented programming translates from it's earliest days to something very recent.

By: Chris Prather on 2009-12-24T01:38:00

Tags:

link

Lies, Damn Lies, and Statistics

UPDATE:

Aldo Cortesi contacted me privately via email with a response to this post. With his permission I've updated this post with the substance of his response and my own rebuttal. The updated sections are marked with UPDATE/END blocks.

END

So after chromatic linked to Aldo Cortesi's post The impact of language choice on github projects I was curious. After reading the post, I was shocked and dismayed at some of the analysis Mr. Cortesi attempts to derive from his data. I brought it up on IRC and decided at first that rjbs's advice is best, "just ignore it."

Obviously that didn't stand, because I saw Flavio Poletti and osfameron both comment about Cortesi's post. Upon second reflection I realized that perhaps there was some nice value to be taken out of the data he presents.

At the time Cortesi extracted his data from github, Perl was the 6th most popular language.1 Cortesi's first two illustrations look particularly nice for Perl. First he pulled out the median number of contributors (emphasis is his).

Most projects have around 3 contributors, with Perl and Java projects having about 5, and Javascript and Objective C around 2.

This means in general that Perl projects have more developers than the other languages measured except for C++. This is a good sign. Next he pulled out the median number of commits (again emphasis his).

Most projects have around 75 commits.

Perl however in his data (again like C++) has a much higher media, nearly 200 commits median. His explanation for this was (to me) very unsatisfying.

The Perl and C++ data, however, seems significant - projects in these languages on average have a much longer commit history. I suspect that this is due to a decline in popularity in these languages. Recall that I collected data only for projects that had recent commits. If fewer new projects are created in C++ and Perl, we would expect projects in these languages to be older, on average.

I think that the sheer fact that Perl (and C++) are both much older languages is enough to explain the discrepancy. Perl has many projects that have converted from one or more version control systems (Moose for example has a revision history that is only a year younger than Git itself, and is considered a young project in the Perl world).

The Perl community also tends to get behind a few good projects. This isn't really obvious unless you're active in the Perl community, there are many many things that aren't obvious unless you're in the Perl community, it actually is a problem but one for a later blog post.

So to extrapolate further, the Perl community tries to engender people rather than create a new project, to use one of the 21 thousand existing projects to solve their problem. This explains why we have a higher median number of contributors to our projects as well as why our projects are on a whole older.

UPDATE:

Cortesi pointed out the following.

The first point where you strongly disagree with me is my conjecture that the higher median commit count for Perl and C++ is due to a decline in popluarity in the languages, which means that my sample is skewed towards "older" projects. You counter that it might just be that Perl and C++ are older, and that this is reflected in the project data. This doesn't sound right to me - for one thing, Perl was first releaed in 1987, and Python in 1990. I just don't think that a 3 year difference over a 20+ year history can explain the size of the effect. One way to approach this might be to look at the rate of project creation over the last few years, which would be easy enough to do.

He's right, I'm simply parroting the stereotype that Perl is older than Python (or even Ruby which came into existence in the mid 90s) when I rightly know better. The stereotype however does have some merit. It's generally accepted that Perl had it's second wind during the dot-com era and that was when Python had it's first wind.

I'm honestly not sure that the data can be conclusive argued one way or the other without perhaps correlating the age of the data (time since first commit) in there as well.

END

Next Cortesi measured number of files touched per commit (emphasis his).

Most commits touch about 4 files, with C++ touching somewhat more, and Perl, Python and Ruby somewhat less.

This is most easily explained by the nature of the dynamic languages that more is done in smaller modules, blah blah blah. Neither Cortesi nor I really found anything interesting in this because it upholds the standard stereotypes.

Next Cortesi talks about Contributors (emphasis his).

The average contributor contributes about 5 commits to a project. C, Objective C and Ruby developers contribute somewhat less, PHP, C#, Java and Javascript developers somewhat more. I suspect the results for C and Ruby are due to projects in these languages receiving more one-off contributions.

Here Perl clocks in at exactly the median. If I were to guess I think the meaning here is that on average Perl projects have on average a larger core group of contributers with smaller one off commits, and that these two facts offset each other. This story reflects the information above (higher median contributer count, older more established projects), as well as the next point Cortesi makes (emphasis his).

For all languages, a small fraction of the committers do the vast majority of the work. This won't be news to anyone in the Open Source community. More interesting, though, is the fact that C, C++ and Perl projects are significantly more "top-heavy" than those in other languages, with a smaller core of contributors doing more of the work.

This really just reinforces the previous point that Perl's projects are older and more established, with a stronger commitment from it's core contributors. This could be read as Perl being a dying language, just like C and C++. This could also be read as these three languages not being fad languages, where people swoop in, commit a whole bunch and then drift off. Really there isn't enough information here to tease out which is true.

Finally Cortesi tries to make a correlation between the number of committers for projects and something. I think however there may be a problem with his analysis. First he measures commits vs committer as a measure of how well languages recruit and retain contributors. Perl here shows up fairly well actually, third only to Python and Ruby. I strongly suspect that the significant discrepancy in data between these languages (there are more than twice as many Python projects included as Perl, and Ruby is four times again as much as Python) may come into play, but I've no evidence to back that up.

UPDATE:

Cortesi noted the following, which is a fair point I overlooked.

Here, I'd like to point out that the graph shows the total commits vs the total committers per project. As such, it doesn't tell us anything about the retention of committers - a committer who makes a single commit and leaves the project is still counted. I've been thinking about how to measure committer retention - perhaps looking at the timespan bracketed by the first and last commits of a committer, as a percentage of the lifespan of the project.

END

The next set of graphs shows the number of commits per day over the first 300 days of a project. Perl here shows a strong decline, the strongest actually. Coming in second is C, then Ruby being the last obviously show a decline (Python and C++ could arguably show a decline, but they just as arguably are flat). The other languages are all flat, or show a slight increase.

A suggestion came up in the comments to Cortesi's that Perl projects tend to be "complete" and move into maintenance mode. Cortesi actively rejects this idea. While I disagree with his analysis2 I think he's correct in refuting this. I suspect that instead Perl projects quickly move to a point where they are obviously inferior to another project and are abandoned.

This story would play out with the earlier arguments regarding the commit count, and the age of Perl projects. The story behind DBIx::Class is a good example (even though it works counter to my argument). Originally Matt Trout used and actively contributed to Class::DBI, DBIx::Class was intended to research ideas for moving Class::DBI's codebase forward. It wasn't until fundamental design differences between Class::DBI and DBIx::Class were discovered that the fork of the community really occured, and even then for the longest time DBIx::Class maintained a CDBI compatible API.

This story plays out more often in the small, and in many of those the research project is found to be fundamentally flawed, or folded back into the parent project, or abandoned due to lack of community interest. The fact that this story plays out again and again in the Perl community is in some ways very ironic considering the Perl motto of TIMTOWDI, but this is the basis of the new motto TIMTOWDI BSCINABTE (pronounced Timtoady Bicarbonate and meaning There Is More Than One Way To Do It, But Sometimes Consistence Is Not A Bad Thing Either).

Finally, it's obvious in the analysis and comments that Cortesi dislikes Perl. He is allowed to have his opinion, obviously to anyone who reads more than one post on this blog I don't share it. I found it particularly dismaying3 however he let his opinion of Perl ruin his analysis, and lead to what he calls "the venomousness of some of the Perl commentators".

I can only assume that the venomousness he is talking about was removed or particularly bad in email, because the comments that stand now appear relatively rational and inline with the tone set in the body. I can't pretend that the Perl community isn't full of loudmouth assholes, I'm one of them, however if people find themselves feeling venomous, they should take it to their own blog. Better yet, take a deep breath and start that new project that is really cool and will change the world, and upload it to github so that the world beyond Perl can see it.

UPDATE:

This is pure conjecture on my part, any opinion expressed here is entirely my own and has not been approved or vetted by Mr. Cortesi.

Aldo seems genuinely surprised at the strength of reaction he had, and in speaking with him his comments weren't intended to be as inflammatory as they came off. I've expressed that the Perl of the past isn't the Modern Enlightened Perl we all know and love (YOU DO LOVE IT RIGHT?!?), and tried to show how things really are in the Perl universe I see rather than the one he's obviously experienced in the past.

END

By: Chris Prather on 2009-12-15T18:40:00

Tags:

link

If You Give a Mouse A Christmas

Jerrad Pierce wrote a Perl Advent Calendar entry that has sparked some discussion in the Moose community. He has revised it two or three times, and the final version is disappointing but not blatantly wrong. As a Moose contributor who has deployed Mouse into production I wanted to give some perspective on the issues that came up.

Jerrad suggests strongly in the tone of his article that Mouse is everything you want in Moose but faster. There are some strong issues with this implication, the first being that there is no way to really know if that is true. Jerrad quotes the Mouse documentation by saying

Mouse is "Moose without the antlers" i.e; lacking the thorny dependencies and added heft giving you a pain in the neck.

But the truth is that the antlers the Mouse documentation is talking about isn't the dependencies (which I've blogged about previously), it is the Meta Object Protocol (the MOP). To quote Jerrad again (from one of his re-writes)

[Mouse] can be a nicer, gentler introduction to the world of Moose. Like the cervine form, the rodent provides a simple means of providing accessors which are more explicit than a generalized AUTOLOAD mechanism, while still eliminating redundant code. Plenty of other fancy OO features come along for the ride, but no "metaprotocol stuff," which some would argue is the raison d'être of Moose.

Mouse implements much of the sugar from Moose, but implements the bare-minimum of an Object System to back up that sugar.

You may be willing to make such a trade-off, but what if you're not writing the code, and instead run into some other module that foists Moose upon you? That author may or may not need all of Moose, but chances are good they don't.

Here is where my problem with the solution provided in this calendar entry comes. Chances are that the developer who chose to use Moose has no clue which pieces of the MOP they rely upon. The MOP in Moose is a kind of an iceberg, everything in Moose is build around it. The thin sugar layer that most people interact with is only the surface of what is going on inside.

This is the power of Moose. You don't need to know what is going on for 90% of the things you do, you just need to know that Moose works, and MooseX::Aliases, or MooseX::Getopt, or MooseX::Storage can hook into the proper places in the MOP and get things done.

Jerrad mentions this almost as an aside though in his calendar entry.

Note that even if other code will compile correctly with Mouse, it's possible the code could be doing some deep introspection and you may end up with Chet rather than Comet. it is therefore recommended that you run the code's test suite against Mouse whether you force it through Package::Alias or substituting Any::Moose.

How confident are you that your test suite includes the proper coverage for your application that you can detect subtle bugs in the MOP? I have a few applications that have high 90%+ test coverage, and I'm not sure they would deal well with having their object system replaced underneath them.

The fact of the matter is that unless the upstream module author designed their application with possible Mouse usage in mind, it simply cannot be a safe guaranteed drop in replacement for Moose. This is why the Mouse documentation say to use Moose instead.

This leads to my last, and sadly personal, issue with this calendar post. I'm an active member in the Moose community. I have been for about three years now. I am one of the people who will have to support the kinds of failure that this well intentioned but reckless advice will cause.

If Jerrad had simply talked to us when writing this calendar post, we wouldn't have reacted so strongly. We could have pointed out the issues in the advice he was giving, and helped him to write a better article that focused on the important part of advocating Mouse as a reasonable replacement for Moose in some circumstances, and the interesting hack he performed with Package::Alias, or Alias.pm, or even the import hack someone in the Moose community suggested.

By: Chris Prather on 2009-12-02T18:14:00

Tags:

link

Blawd: Now With Plack Control

miyagawa, the esteemed ring-leader behind the PSGI/Plack tonight in response to an idle comment about wanting to move Blawd's simple server command over to the PSGI standard supplied me with a quick patch to do just that. So as of the most recent commit blawd server --repo myblog.git should "just work" with any environment that speaks PSGI. The code itself was exceptionally elegant and I thought it deserved to be shown off.

has host => ( isa => 'Str', is => 'ro', default => 'localhost' );
has port => ( isa => 'Int', is => 'ro', default => 1978 );

sub _build__http_engine {
        my ($self) = @_;
        HTTP::Engine->new(
            interface => {
                    module          => 'PSGI',
                    request_handler => sub { $self->handle_request(@_) },
            },
        );
}

sub execute {
        my $self = shift;
        my $app = sub { $self->_http_engine->run(@_) };
        Plack::Loader->auto( host => $self->host, port => $self->port )->run($app);
}

The old version was based on HTTP::Engine the new version takes advantage of the HTTP::Engine plack support.

By: Chris Prather on 2009-12-02T00:00:00

Tags:

link

Software Delivery!

I was just reading Matt Asay's piece about Domino's using open source to build out their multi-million dollar order fulfillment system. His take away quote got me thinking.

There will still be a need for companies like SAP, of course, as there are broad industry needs that a company or open-source foundation can satisfy. But for strategic IT projects, we're likely to see more open source plus internal development, and less packaged software purchases.

The gist of this is that these companies like Domino's will be building up their internal IT departments to largely take on the kinds of projects that they would previously buy enterprise grade software from Microsoft or SAP. I disagree.

I think (or perhaps hope) that this is the first step in a further evolution. There is no long term economic reason why Domino's should be in the the software development business. That's not their core business. Saying that the future of open source jobs is working for the Domino's internal software development group is like saying 20 years ago that the future of open source is the Operating System.

I suspect in 20 years time that there will be (or recently have been) a shift from large in-house IT teams, to outsourced teams of consulting companies and independent contractors. Teams of people already surround open source projects. Some of these people are in-house developers at large corporations like Asay's article talks about (the Moose community for example has people from Walmart, the BBC, and Omni Hotels). Some of these developers work at smaller consultancies (again Moose has people from Infinity Interactive, Best Practical, and my own Tamarou1). Some of these people are even independent contractors.

It seems like a very short step for these organizations do the heavy lifting for an enterprise level IT Project. The Corporate Sponsor could then choose to either hire a skeleton maintenance staff, or keep one or more of the project's organizations on retainer.

In his book The Four Hour Work Week, Tim Ferris coined a term 'geo-arbitrage'. Arbitrage is the practice of taking advantage of a difference in prices between two or more markets. Geo-arbitrage is taking advantage of physically distinct markets (say India vs Europe). Geo and temporal arbitrage are what cause the radical lowering of cost for open source2. Developers who are emotionally committed to a project somehow find non-monetary ways to value their time.

Currently large corporations leverage geo arbitrage with a few very large strokes. They'll off-shore their internal developments staff (setting up a development office in Mumbai or Beijing for example), or they'll hire an external company to perform a large project. I don't think this will change, but I think that this will become much more sophisticated as time goes on. Large consultancies will themselves outsource development rather than hire more developers and maintain a large staff, or perhaps smaller consultancies will band together to tackle projects normally handled by the larger consultancies.

The benefits for companies like Domino's are enormous. For starters smaller focused software shops are already experts in their specific tool chain and domain. Teaching a programmer who has already built six order fulfillment applications enough about the Pizza industry to drive an application story is easier than doing the reverse with an executive in the Pizza industry, or even a talented programmer who has no relevant experience.

Second finding and retaining good developers is hard. Finding committed developers with a passion for an Open Source stack is even harder. Scott Adams (yes Dilbert's creator) recently noticed a trend.

Imagine a world where managers always recognized and rewarded their most capable people. It would be hard for a rational employee to leave a great job for a ten percent chance of creating something even greater. But leaving a boss who is Satan's learning-challenged little brother is relatively easy. And if the general economy isn't serving up wonderful job opportunities at other companies (thanks in part to bad management) then you can see why people gravitate toward starting their own companies.

The best developers are already thinking of striking out on their own. These are already the people who are clued in. Why not let them step out on their own, and hire them back with a few of their talented friends in the community as a consultant? That IT manager may have been incompetent as an IT manager, but he or she might make an excellent liaison to the new consultants. Sometimes it is easier to work with someone than for someone.

Also, some corporations are limited by law or economic reasons to their local market they are and they may have to make decisions based not on what is best but rather on what is available. A consultancy or contractor may have a lot more flexibility in the options they can bring to the table. Perhaps they have experience handing telecommuter teams, while your company doesn't. They might be able to hire a developer from Israel, who lives part times in France, and can finish that project in a week and a half.

I'm not trying to gloss over the downsides of out sourcing. It is by no means always a rosy magical world of happiness. I am simply trying to illimunate the current efforts at outsourcing as the clumsy beginnings of what will become a much more sophisticated market.

Some may claim that this will inevitably lead to the same situation we have today where the consultancies of tomorrow have a single product that they schlep from project to project. They may be correct, time will have to tell. I suspect that the truth in 20 years will be even stranger than we know.

Update: Apparently the Perl Ironman blogging contest wants me to mention CPAN as well for it to show up.

By: Chris Prather on 2009-11-27T15:36:00

Tags:

link

Perl Oasis 2010: Discount Hotel Rates End

November 25th is the last day for the Perl Oasis special Group Rate. The rate is $75 USD / night for what according to other sources is a $135-$150 / night hotel room.

Perl Oasis is a one day workshop in Orlando Florida focusing on Modern Enlightened Perl. This year we have speakers from three continents, and the entire Perl spectrum speaking. The Call for Speakers is still open so you can submit your talk as well!

By: Chris Prather on 2009-11-24T20:45:00

Tags:

link

What Stops Me From Using Perl6 Today

I have to confess mst asked me to step forward and make a comment about the Perl5 & Perl6. I suspect because I'm a prime example of a person who's deeply involved in what masak calls the Perl5 story. This is because I've been bound up tightly with the Moose community for a while, and I've recently founded a company that is doing Modern Enlightened Perl development. My bread is buttered by Perl5.

Recently because of mst and masak sparking a conversation I have started taking a really close look at Perl6. One of the things that struck me was how polished and complete the core Perl6 language was, and the Rakudo implementation.

This post started out as a much more whiney response to bakkushan's post of the same name. For that version of this post I set out to compare Perl6, specifically Rakudo, to my own cherished Moose. The Example object I came up with is a stripped down version of Blawd::Entry::MultiMarkdown.

use 5.10.0;
use MooseX::Declare;

class Blawd::Entry {
    use MooseX::Types::DateTimeX qw(DateTime);
    has [qw(title author content filename)] => (
        isa      => 'Str',
        is       => 'ro',
        required => 1,
    );
    has date => (
        isa      => DateTime,
        is       => 'ro',
        coerce   => 1,
        required => 1,
    );
    has headers => ( isa => 'Str', is => 'ro', default => '' );
    has commit => ( is => 'ro', required => 1 );
}

The Perl6 version is pretty straight forward.

use v6;

class Blawd::Entry {
    use Temporal;

    has Str $.title     = die "Str title Required";
    has Str $.author    = die "Str author Required";
    has Str $.content   = die "Str content Required";
    has Str $.filename  = die "Str filename Required";
    has DateTime $.date = die "DateTime date required";
    has Object $.commit = die "Object commit required";
    has Str $.headers   = '';
}

The Perl6 version is shorter, and arguably more elegant. TimToady helped me figure out the Perl6 equivalent to Moose's required => 1. You just set a default that will throw an exception when evaluated.

But I've lost the type coercion on DateTime. In the Moose version it is provided in the MooseX::Types::DateTimeX library and enabled by the isa => DateTime, coerce => 1 parameters passed into the date attribute constructor. I know this can be done in Perl6 and after several furtive attempts to find it in the documentation as well as a question that TimToady answered on #perl6 I finally found a solution.

class Int is also { method Time { Time.gmtime(self) } };

Trying to shoe horn that in after a second beer at 1:30am simply wasn't producing the desired results1. Think about that for a second, my complaint was I couldn't get the Type Coercions to work as elegantly as I wanted. That's a far cry from "half finished vaporware".

So while I have reservations about some of the current design regarding the metaobject protocol (I have offered and am still in dialog with the Perl6 people about helping them steal from Moose), Perl6 is a much more complete picture than the general grousing in the Perl5 community would give you.

Does that mean I've jumped ship and will start hacking in Perl6? Probably not. While Perl6 may have more polish than I expected, and is a project that is well on it's way to being complete, it lacks some fundamental things I love about Perl5. The biggest of which is CPAN.

Going back to my Blawd app as an example. Blawd is only 814 lines of code because I leverage CPAN. If you look at the dependencies from the Makefile.PL you'll see a tight list.

requires 'aliased';
requires 'Bread::Board';
requires 'DateTime';
requires 'DBI';
requires 'Git::PurePerl';
requires 'HTTP::Engine';
requires 'Moose' => '0.92';
requires 'MooseX::Aliases';
requires 'MooseX::Types::DateTime';
requires 'MooseX::Types::DateTimeX';
requires 'MooseX::Types::Path::Class';
requires 'namespace::autoclean';
requires 'Path::Class';
requires 'Text::MultiMarkdown' => '1.0.30';
requires 'Try::Tiny';
requires 'XML::RSS';

Some of these are hard requirements, Git::PurePerl for example. Some of these are soft requirements, DBI for example I only use in the MoveableType exporter, and HTTP::Engine is only there for the experimental server back-end.

The point however is that I have 15 dependencies for code I didn't have to write. If I wanted to start hacking up a Blawd in Perl6 I'd have to port Git::PurePerl, which itself turn requires 11 modules.

'Archive::Extract'           => '0',
'Compress::Raw::Zlib'        => '0',
'Compress::Zlib'             => '0',
'Data::Stream::Bulk'         => '0',
'DateTime'                   => '0',
'Digest::SHA1'               => '0',
'File::Find::Rule'           => '0',
'IO::Digest',                => '0',
'Moose'                      => '0',
'MooseX::StrictConstructor'  => '0',
'MooseX::Types::Path::Class' => '0',

Now Perl6 doesn't require some of these. Moose will hopefully not be required in Perl6 in the not too distant future. But what about Digest::SHA1? A quick google didn't find anything suitable as a replacement, so I'd have to re-write that as well. What it boils down to is there are far more Yaks than I want to shave in the Perl6 ecosystem. Just to replace my little 814 line hack, I'd have to write a Git implementation, a MultiMarkdown renderer, and an RSS feed generator.

I've added #perl6 to my IRC client. I'm keeping a closer eye on it, but for now I say long live Perl5, further up and further in.

By: Chris Prather on 2009-11-16T14:12:00

Tags:

link

Accessors, what's in it for Me

So there has been some discussion recently on various places I almost never go to on the internet. That has bled over into #moose-dev, the developer channel for Moose.

The argument came up apparently that there's no point to an accessor that is just a glorified wrapper around hash key assignment. The basic assumption is that Moose's accessors are basically:

sub foo { shift->{foo} = shift; }

Which isn't true. But let's assume for a moment it is. What does this buy us over simply saying $obj->{foo} = $value. At first glance not much. Now the Moose crowd's answer was "but we can add a ton of extra stuff in there for validation, and coercion", and that's true but that is missing the fundamental point. Encapsulation. People using your Object should never have to know if they're accessing state or behavior.

What if I decided to re-factor my object so that foo is now a delegate to a FooThing object.

sub foo { shift->foo_thing->{foo}} = shift; }

If I'm using direct hash access I have to go and update every single line of code that uses $obj->{foo}. That's broken. The point to encapsulation is that I can change state to behavior, or behavior to state in one place and not have to fix any of my client code because it's safely abstracted behind an API.

Perl5 has several ways to fix this. You can do what Moose does, and make it dead simple to just make accessors for everything and build a up a culture that smacks you on the wrist if you violate encapsulation. Alternatively you can go out of your way to hide the fact that you're changing state to behavior, or behavior to state by using tie or lvalues.

One way is simple, and well tested. The other way is full of pitfalls and increases the amount of "Magic" in the system by using obscure creatures from the Perl5 bestiary.

By: Chris Prather on 2009-11-13T15:14:00

Tags:

link

Everybody Wants Some … CPAN

So the twitters were all a … well twitter … with the People want CPAN :-) thread. This had some amazing synchronicity with the Perl talks we gave at Big Lamp Camp in Nashville this weekend. The main thrust of Stevan and Cory's talks were "It's the CPAN stupid."

However reading through the Python thread I've seen some places where people are ignorant of the reality of CPAN.

CPAN is a set of hierarchical servers

The core CPAN ecosystem is a filesystem and three index files. I have a script I borrowed from someone that lets me mirror the entire CPAN repository around using just rsync. The CPAN tools will work on this local filesystem as well as they do on any of the remote ones. There is no hierarchy there is simply an acyclic digraph.

There is one unified distribution format.

This depends on how you look at it. There are at least three major solutions for building a CPAN package each having it's own affordances and constraints. For example all of my modules use Module::Install because I find the declarative syntax useful and like the fact that it bundles the installation requirements along with the package. However some people loath the fact that it bundles itself and prefer Module::Build which is a pure perl solution, while yet others rely upon ExtUtils::MakeMaker (which Module::Install uses internally).

The fact that users don't even notice that this difference exists however is awesome. This is the whole point of TIMTOWTDI BSCINABTE (There is More Than One Way To Do I, But Sometimes Consistency Is Not A Bad Thing Either). We have one consistent interface for three competing technologies.

There is a single consistent interface

Actually there are at least two clients for CPAN, CPAN.pm and CPANPLUS.pm. Each comes with it's own command line script, cpan and cpanp respectively. And, just like the distribution formats, they have radically different guts with different constraints and affordances.

They both however work rather identically from the client perspective.

cpan -i Moose  # install Moose
cpanp -i Moose # install Moose

There is a BuildBot on the Server

CPAN Testers are brilliant. They like everything in Perl are a wholly distributed volunteer effort. The two cpan clients both have supported uploading a snapshot of the test results for every run of a test suite for almost as long as I can remember. One day someone decided to build a script that just downloaded every module uploaded to CPAN, run the installation up to the test suite and report it. Then someone else got in on it, and someone else … eventually it became a small contest to see who had the most reports covering the most platforms. Now they cover (as of last month) 13 Perls on 11 operating systems across 57 platforms.

The quality of these tests is somewhat suspect too. There are no coverage requirements, and code coverage doesn't really mean anything. The Perl community has also gone through several testing related fads with regards to developer vs. end-user oriented tests. There are some debates still going on about the "opt-out" nature of installing CPAn packages because some large dependency chain installs can be obtuse for the end-user to debug if a test fails somewhere deep in the chain.

The fact that Testing is now part of the defacto CPAN ecosystem is awesome but the important part isn't the "BuildBot", it's the collection and aggregation and reporting of the statistics.

CPAN Deals with Versioning

This is pretty much false. CPAN relies upon Perl's ability to detect version numbers and Perl is incredibly simplistic. As long as a version can be numerically compared as greater than another version that's about all the promise CPAN can give you.

CPAN in fact can make matters worse because it assumes that the computationally greatest version number on CPAN is the "best" version for a given package. The CPAN ecosystem has no way to specify a dependency on only version N of a package.

CPAN is Awesome, but CPAN sucks

CPAN is a loosely organized large pile of semi-tested crap. It follows Sturgeon's Law that 90% of everything is crud pretty closely. But with the current size of CPAN that means that there are approximately 1,917 packages that aren't crud. Finding these packages is a continual conundrum.

The fact is however that if the problems are social (should testing be opt-in or opt-out? how do you find a good package? what do you do about versioning?) then the technical solution is doing it's job incredibly well. In a very significant way CPAN is the Perl language, without it you couldn't have a post-modern Object System, simple Tail Call Optimization, Parser Level syntax extensions, or any number of other low level adaptations to the language.

UPDATE

So apparently people found this post interesting and I've had a few people metion problems with it. I've fixed the cpan/cpanp command line since they both will accept -i but only cpan will let me do cpan ModuleName.

Also I've been told to link to The Zen of Comprehensive Archive Networks which explains in far more detail how CPAN works, and was written by the masterful Jarkko Hietaniemi.

By: Chris Prather on 2009-11-10T12:04:00

Tags:

link