▬▬▬▬ ▬▬ ▬▬▬ ▬ ▬▬▬▬▬▬▬ ▬▬.

I can't find the first epigraph but if I had to guess it must be a quote from Tolkien accompanying one of the releases Larry Wall did. The source code for Perl itself is liberally littered with Tolkien quotes.

One of the reasons I wanted to do a Perl release was to have an opportunity to choose my own epigraph (weird motivation, but true). I had a few criteria in mind.

First, I wanted to choose a writer I respected as a writer, something I'd want other people to read. Second, I wanted to pick a new author (not Tolkien ;). My first inclination was to find something in one of the Kushiel Trilogy books by Jacqueline Carey, who is one my favorite authors, and probably not that well known in the Perl community.

One of the main themes in these books is love as a motivation for sacrifice. I think that the people who work on Perl are at least in part motivated by love. We have love for the language and for the community. We could all spend our time on other things like making more money, sleeping, or watching more TV, but we hack on Perl instead.

Unfortunately, finding a quote isn't all that easy. It's been a few years since I read the books, and I couldn't remember any particular piece off hand. I tried using Amazon's "look inside" feature, but I just couldn't find anything. I started browsing my bookshelves looking for something else.

It finally came down to a quote from Matt Ruff's Set This House in Order and the one I chose, from A Wizard of Earthsea by Ursula K. LeGuin. The Ruff quote was great, but it specifically refers to being born at age 26, and Perl just turned 24 (on December 18, 2011), so I thought that might be a little confusing. Maybe I can volunteer to release 5.19.6 in December of 2013.

The quote I did choose is:

Ged had thought that as the prentice of a great mage he would enter at once into the mystery and mastery of power. He would understand the language of the beasts and the speech of the leaves of the forest, he thought, and sway the winds with his word, and learn to change himself into any shape he wished. Maybe he and his master would run together as stags, or fly to Re Albi over the mountain on the wings of eagles.

But it was not so at all. They wandered, first down into the Vale and then gradually south and westward around the mountain, given lodging in little villages or spending the night out in the wilderness, like poor journeyman-sorcerers, or tinkers, or beggars. They entered no mysterious domain. Nothing happened. The mage's oaken staff that Ged had watched at first with eager dread was nothing but a stout staff to walk with. Three days went by and four days went by and still Ogion had not spoken a single charm in Ged's hearing, and had not taught him a single name or rune or spell.

I think this quote works on several levels. First, it reflects the difficulty of hacking on the Perl core's C code. It's some serious magic, and you won't become a great mage all at once. Second, this same dynamic of slow learning applies to programming in general. It seems like great magic, and you wish you could master it all at once, but it takes quite some time before you've figured it out. This is actually one of the themes of all the Earthsea books, that mastery takes a long time, and that maybe you never really become a master. Instead, you just learn clearly how little you actually understand.

I feel like this with programming all the time. Even if I felt like I really "got it" I can always look back at my work a year later and see just how clearly I didn't "get it" at all.

Unfortunately, choosing Ursula K. LeGuin probably doesn't satisfy my desire to pick someone who might be new to people in the Perl community. Oh well, maybe next time!

I hope that in the future other Perl release managers will write blog entries similar to this one explaining the quotes they chose. I'm always curious what the quotes mean to the person doing the release, although occasionally they're quite straightforward. I added an entry to the Perl Release Manager's Guide asking folks to blog about their epigraph after the release.

Here's looking forward to Perl 5.15.7 (and it's accompanying blog entry).

CS doesn't provide anything like JS's with block. That makes sense, because with in JS is completely insane and broken. But sometimes you want to be able to say "given this object, call a bunch of methods on it". You can of course write something like this:

foo = new Foo
foo.bar(42)
foo.baz(84, "x")

Or in CS:

foo = new Foo
foo.bar 42
foo.baz 84, "x"

If you want a more Dee Ess Ell style, you can reach for this in JS:

foo = new Foo
with (foo) {
    bar(42)
    baz(84, "x")
}

In typical JS fashion, with is a nightmare. Douglas Crockford has a good write up on why it's broken.

The other alternative in JS is to use method chaining:

foo = new Foo
foo
    .bar(42)
    .baz(84, "x")

Unfortunately, because of CS's parsing rules, method chaining is kind of fugly, requiring explicit parentheses. Also, method chaining requires explicit cooperation from the methods being called.

So I came up with this alternative in CS:

foo = new Foo
(->
  @bar 42
  @baz 84, "x"
).call foo

This creates an anonymous function and then invokes the Function.call method on it. The call method takes its first argument and makes it the method's invocant, so inside the function this is now equal to that argument (foo in the example above).

I think this syntax could make for a nice alternative to method chaining when you want to call methods on the same object repeatedly. The only thing I don't like is that the invocant ends up at the end of the block. I really wish I could write something like this:

foo = new Foo
using foo ->
  @bar 42
  @baz 84, "x"

I could get pretty close by defining my own using function:

using = (invocant, method) -> method.call invocant

foo = new Foo
using foo, ->
  @bar 42
  @baz 84, "x"

But then I need to have that function around everywhere I want to use it, which is a hassle. For now, I think I'll try using the (anon).call version and see how I like it.

My general policy is to approve all comments, even the obnoxious trolling stuff that follows any mention of a code of conduct. So if you submitted a comment and it didn't show up, I'm sorry about that.

Just now, I found three legit comments on my last post I'd accidentally spam-bucketed. I've now published them, but anything on older posts is long gone.

You'll notice I've added a captcha form to the comments. It's annoying, but it should slow down the spam, I hope.

If I dropped a comment of yours, feel free to re-submit it, and I will approve it soon.

Also, note that if you log in with an OpenID login (or some other authentication method), your comment is automatically approved.

Jesse's plan is interesting, and in theory sounds like a good idea. Unfortunately, it brings up some incredibly thorny issues and may not be technically possible. Even if it is possible, it's likely that lexically preserving backwards compatibility will not work for every proposed feature.

This is an old discussion. The p5p list has been debating backwards compatibility versus evolution for years.

One thing that keeps coming up is that backwards compatibility is important for people who are using their system-installed Perl. If they upgrade from RHEL 5 to 6, they'll move from Perl 5.8.8 to 5.10.1, and they can't really avoid that. People who are stuck in this situation are very concerned about backwards compatibility.

I'm not very sympathetic to this view. You have an uncontrolled dependency in your system, and you expect the maintainers of said dependency to essentially keep your code working for free. But my sympathy is irrelevant, because I'm not in charge. I don't think p5p as w whole (or Jesse as a one) will ever tell these users to just deal with breakage.

All of this leads up to the title of this entry. Why do people use the system Perl? Well, answer number one is that it's really convenient. Perl is already there, so why not use it?

If we can make it easier to not use the system Perl, maybe we'll feel a little freer to (very slowly) break backwards compatibility. We already have perlbrew, which is a great tool for development, especially when you need to test code with more than one version of Perl.

I've seen some people suggest that somehow perlbrew can replace the system Perl for an application, but I don't follow that logic. If I'm running an app across thirty servers, do you seriously expect me to run "perlbrew install perl-5.14.2" on each one? That's nuts. Package systems were invented for a reason.

Wouldn't it be cool if we (as a community) provided a set of "official perl.org" packages of Perl. After all, we're programmers, and this is a task that's ripe for automation. These packages would install under some location like "/opt/perl-5.14.2". For each version, we might provide both threaded and non-threaded versions.

Being able to keep a consistent Perl version across system upgrades will prevent the "I upgraded my OS and all my Perl code broke" problem. As a bonus, this might also make it easier for people to upgrade Perl more quickly if they want to. Not being tied to the system Perl is good for people who want stability and people who want to upgrade faster.

Putting this on perl.org and calling it official is an important part of this plan, since many sysadmins are rightly suspicious of random packages found on some random dude's website.

What do people think?

I think the upshot of this is that announcing a possible class isn't a good idea. All this does is create uncertainty for potential students and discourage signups. In the future, there's a couple things conference organizers and I can do to make this class (or any class) more successful.

First, just announce the class. Don't say it'll only happen if only X people sign up. The option to cancel for lack of signups is always available.

Second, the class needs a concrete date and time well in advance. I suspect that part of the reason people didn't sign up for the Moose class is that they wanted to see what it would conflict with first. Would you want to miss Damian to come to my class? Hell, I'd rather see Damian than come to my class!

Even if the whole schedule isn't ready, things like classes and major keynotes should be scheduled at least two months in advance.

As a corrolary, organizers need to know how long the class takes well in advance. I didn't communicate that clearly to the PPW folks. For the record, the Moose class needs around 6 to 6.5 hours of class time, excluding lunch.

I'm happy to say that as of last week, all of my work has been merged into the blead branch of core, and will be in the next release of Perl.

Here's what I did ...

We now have an entirely new OO tutorial. This tutorial has two parts. The first is an introduction to OO concepts. Some people may come to Perl without a background in another OO language, so defining basic concepts is important. This part defines these concepts in terms of how Perl implements them, so even if the reader has some OO background, skimming this section will still be useful.

The second half introduces three OO systems from CPAN and gives short examples of how to use each one. In 2011, it just doesn't make any sense to tell people how to roll their own OO code in a tutorial. The systems I wrote about are Moose, Class::Accessor, and Object::Tiny. I also mention Role::Tiny, since roles are awesome, and you shouldn't have to use Moose to use roles.

When I merged this tutorial, I deleted all the old tutorials. Those were perltoot (Tom's object-oriented tutorial for perl), perltooc (Tom's OO Tutorial for Class Data in Perl), perlboot (Beginner's Object-Oriented Tutorial). I also removed perlbot (Bag o' Object Tricks (the BOT)). All of these were extremely outdated and contained a number of dubious recommendations.

Don't take this as a criticism of Tom, Randal, or other people who worked hard on those docs. They were great when they were written, but the state of the art in Perl OO has changed a lot in the past 10-15 years. If Perl 5 is still in use 10 years from now, someone will be deleting my tutorial then!

I also revised perlobj. Some of the old content remains, but it has been rewritten, reordered, and expanded. I hope that it is now a 100% complete reference to core Perl OO features.

If anyone reading this has any constructive feedback on these docs, I'd love to hear it. I really want to get these new docs into excellent shape before Perl 5.16 ships in spring of 2012.

What would a code need for me to consider it acceptable?

First, it needs to define acceptable conduct. The Reasonable Person Principle section from the YAPC 2011 code is good, but something much simpler is fine too. In fact, I'm fine with something as simple as "we expect all conference attendees to treat each with respect".

The policy should outline some explicitly unacceptable behaviors. This needs to be there for the benefit of people who are clueless. At a minimum, this should forbid sexual imagery in slides, unwanted sexual attention (or maybe just unwanted attention), and verbal abuse. If the conference has exhibitors, it should also forbid sexualized imagery and clothing for exhibitors (in other words, no booth babes). The example anti-harassment policy in the Geek Feminism Wiki lists more unacceptable behaviors, and that's probably a good list to copy. But really, my concern isn't that the policy have exactly the right list, just that there is some effort to outline the most egregious unacceptable behaviors.

It doesn't hurt to say something about what the penalties for violating the policy might be, but I don't think that's critical. The existence of a policy implies that violators may be ejected from the conference at the discretion of the organizers.

Finally, it needs to include an explicit reporting procedure that includes a way for attendees to report incidents via phone and/or email. In other words, there needs to be a way for people to report incidents without finding a conference organizer in person (which may not always be easy enough to do).

Ideally, I'd also want to see an internal policy for conference staff and volunteers that gives some guidelines on how to handle these incidents.

I don't expect my declaration to cause a problem for any future Perl events I'd want to attend. The last few conferences I've attended have had some sort of policy, and I expect these to become much more common in the future.

If you're also a frequent speaker (or infrequent, or not a speaker at all) at Perl events (or non-Perl events), please consider joining me in this pledge.

I wrote some code to manage the mirroring, which can be find in my git-bits repo. It's not ready for CPAN, but it might be useful to others who want to do something similar.

Here's some modules that I own (or co-own) that need some love:

• DateTime-Format-Mail - has some open bugs that could use some attention.
• DateTime-Format-MySQL - I may have a new maintainer lined up, but the more the merrier, I suspect.
• DateTime-Format-Strptime - I took co-maint on this to do a few quick fixes, but it could use more attention.
• DateTime-Locale - I have a vague plan to convert this to use libicu or something like that, but I am lacking tuits. The data is quite out of date at this point. If someone wanted to do just take the existing code and make it work with the newest CLDR data, that'd be fine, but you can't change the API unless it's necessary to support new data.
• HTML-WikiConverter-MultiMarkdown
• MooseX-Singleton - I don't bother using this any more. It's more trouble than it's worth.
• Params-Validate - could use an XS expert to fix some bugs I just can't figure out.
• ShipIt-Step-CheckVersionsMatch - I'm down with dzil.
• Anything else - if you're dying to work on something I've been neglecting, let me know.

All of these modules should be in a git repo on my server.

Contact me via email if you're interested.

I do sympathize with people who don't like these policies, and think they should be as short as possible. Isn't it obvious that some things are unacceptable? Shouldn't we be able to "just" act like adults and treat each other with respect? Do we really need all these rules stated up front?

A code of conduct is not written for the vast majority of attendees, who act reasonably and treat each other with respect. They're written for two groups of people. First, the code exists for people whose idea of what's acceptable falls outside of the community standards. Having a policy in place may help them recognize that certain behaviors aren't okay. After all, most of us wouldn't fill our slide decks with sexual images, because that's obviously a bad idea, but it still happens. Second, the policy is for people who are concerned that they may be victims of harassment at a conference. Having a code of conduct makes it very clear that the conference organizers take this issue seriously. It also gives them clear guidelines on reporting incidents.

Calling it a "code of conduct" may be a bit misleading. We need more than just a list of expectations. We also need guidelines for reporting harassment and a policy for dealing with people who fail to follow the code of conduct. This is important because it helps reassure attendees who may fear harassment that there is a mechanism for dealing with it. A code of conduct all by itself, absent a reporting procedure, is like having laws without a way to report infractions to the police.

The Geek Feminism Wiki has an example anti-harassment policy that makes some important points. I really like the template they provide for internal use with conference staff that gives some specific information on how to handle issues that arise.

One of the things I dislike about it is the description of harassment, which says "Harassment includes offensive verbal comments". The problem is the use of word "offensive". This seems innocuous at first, but it's awfully subjective. There's really no consensus on what constitutes "offensive", other than whether or not a particular person is offended. A good example might be using the word "chick" to refer to a woman. I know women who find this offensive, and others who don't.

A closely related problem is that this example policy doesn't encourage any sort of mediation. In many cases, both the offended person and the offender have legitimate arguments. An ideal policy would encourage the two people to discuss the issue together and resolve the issue amicably. In many cases, it may be sufficient for the offender to say something like "I'm sorry, I didn't realize that saying X would bother you, I'll be more mindful of your concerns in the future".

(Note that the issue here isn't whether the word "chick" is acceptable. The important point is that both parties may have legitimate claims, and the ideal outcome is for both parties to agree on how they can get along in the future, so they both can enjoy the rest of the conference.)

In the YAPC::NA blog discussion, one issue mentioned was not wanting to have a list of specific topics or words which are forbidden. A list of words is a red herring. I've never seen such a policy. The Geek Feminism Wiki policy does list specific issues such as comments related to gender, race, sexual orientation, etc. The concern I've heard about this sort of phrasing is that someone will do something not specifically on the list and then try to be a rules lawyer when they're called on it.

One way to deal with this is to start with a general "don't be an asshole" section. That's what the YAPC::NA 2011 Code of Conduct does. Then there can be a list of some specific offenses (sexual imagery in slides, harassing photography, belittling comments, inappropriate physical contact, etc. Finally, the policy can say "harassment includes, but is not limited to [list of things]".

The reason to list specific things is that not everyone agrees on what "don't be an asshole" means. Past incidents at a variety of conferences make this very clear. Listing specific past issues really can't hurt, and it could help.

Overall, I think the YAPC::NA 2011 Code of Conduct is a good start. I'd add a list of specific offenses after the opening "Reasonable Person Principle". I'd also remove the bit about recommending a restraining order. This seems somewhat out of place. None of the conference incidents I've read about have been the culmination of a long-term dispute between two people, so a restraining order isn't really relevant.

Finally, the policy needs more explicit guidelines on how to report harassment. In particular, it should includes names, phone numbers, and email addresses for key conference organizers. It may not always be obvious to a conference newbie who the organizers are, and they may not be able to find one in person.

Conferences also need an internal document like the one in the Geek Feminism Wiki. This document should be distributed to all volunteer staff at the event.

I'd like to see a standard policy adopted for all Perl events. At the very least, TPF can work with the community to create a required policy for TPF-sponsored events.

With Google Plus, I can categorize these "friends" into different circles. How awesome is that? Most of the people I've had contact with on Plus are people I know through programming, so I made a "Geeks" circle and started filling it in. Right now that circle has 113 members, compared to 8 in friends.

This really appeals to the uptight organized engineer in me, but then I realized that this doesn't any real problem.

I've never liked Facebook, and circles don't make me like Plus any more. My problem with Facebook isn't that I need to categorize the incoming stream of info based on my relationship with people. The problem is that the incoming stream of info is almost entirely uninteresting!

With circles, I now have multiple streams of totally uninteresting info. Here's a sampling of what I see in my Geeks stream this morning:

• Robert Rothenberg says that it's raining.
• Robert Rothenberg asks "Have you looked at the source code of a G+ page? It's all JavaScipt, and dynamically creates the page from a data structure. Interesting...."
• Piers Cawley still has to write some slides for OSCON.
• Curtis Poe posted a video of his daughter.
• Kang-min Liu (aka Gugod) posted something in Chinese.
• Karen Pauley made some chili con carne.

I've categorized people based on my relationship to them, but what I really want is to categorize the things they write. Of the items above, only two of them are geek-related, and only one of them is really interesting to me as technical information.

So what did doing the work of putting people into these circles gain me? Absolutely nothing. I'm still left wading through a torrent of stuff to fish out the few interesting bits.

This is exactly the same problem I've always had with Facebook.

Of course, this problem is already solved. The solution is called "tags" or "categories". I care more about the topic than the writer, though both are important. Just knowing who wrote something isn't very helpful.

And yes, I know that circles do solve a real problem for some people. If I posted a lot of personal stuff on Facebook then circles might actually be useful for me.

Disclaimer: When I say that your content is "totally uninteresting", I mean to it's not what I am interested in. I'm sure Curtis's daughter is totally adorable.