Recently in Programming Category

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

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

I'm going through the Netflix movie rating interface right now rating films & tv shows to try to improve my recommendations. Sometimes after you rate something it asks you how often you watch films of a certain category. Presumably the category the thing you just rated belonged to.

Some of the categories make sense, and some are completely insane. I can't figure out how they could possibly be useful in determining what I like. Some good examples ...

• Parks and Recreation - NBC TV Shows

  I don't give a flying crap what network the show is on. I can think of several other categories it belongs to that seem more relevant (sitcom, documentary approach sitcom, etc.)

• 28 Days Later - Viral Plague Movies

  Yes, I love those viral plague movies. But bacterial and fungal plague movies suck. Of course, what's really silly is that this is obviously a zombie movie, not a plague movie. The mechanism of zombiefication is really not all that relevant.

• Evil Dead - Demon Movies

  Not horror, not comedy horror, not indie horror. Demon movies. Yes, because horror movies with non-demon monsters are so different.

• Lust, Caution - WWII Movies

  Ok, yes, technically, this is a movie set during World War II. Of course, when people think of WWII movies they generally think of movies about American involvement in the war, or maybe at a stretch things that happened in Europe. This is a movie set in China, in Chinese, with Chinese actors. I suspect most people think of this as simply a foreign movie or a Chinese movie.

• Religulous - Spiritual Documentaries

  Uh, WTF?

• The Blair Witch Project - Wilderness Survival Movies

  Ok, yes, they're in the wilderness. And yes, they're trying to survive. But again, WTF?

It seems like in many cases, they've identified some incidental feature of the thing in question and decided it is somehow meaningful.

Anyway, I'd love to hear comments from people who understand recommendation systems better. Do these categories actually make sense?

Today I had the privilege (or punishment?) of releasing Perl 5.15.6, the latest monthly dev release of Perl 5. Part of the Perl release tradition is to include an epigraph with each release. The epigraph is a quote of some sort that goes at the beginning of the release announcement.

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).

For many years, the VegGuide site has been hosted for free at Xmission, courtesy of Eric Waters. Eric has recently moved to a new position and is no longer at Xmission, so it's time for us to find a new host.

Update: The site is owned by my animal rights group, Compassionate Action for Animals, and we are a 501(c)(3) non profit organization.

If anyone in the lights of these pixels could offer free or cheap hosting for this site, please let me know.

The site needs a dedicated host, either real or virtual, with at least 1.5GB of memory and 20GB of disk space. It's bandwidth use is fairly modest, approximately 800MB of outgoing traffic per day at the moment (around 24GB per month). Incoming traffic is about half of that. However, we'd like room to grow in that regard, as I'm hoping we'll be able to increase usage over the next couple years.

We can take care of all the sysadmin bits, so all we need to start is a box running Ubuntu Hardy and the site will be good to go.

Thanks again to Eric and Xmission for hosting the site gratis all these years.

I've been playing with CoffeeScript (CS) lately, and I really like it. JavaScript (JS) is full of annoyances that make coding more tedious and error-prone that it needs to be. CofeeScript does a good job of fixing many of those annoyances.

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 blog has been getting absolutely flooded with spam recently (c. 4,000+ in the last few days), and I've accidentally sent some legit comments to the great spam filter in the sky. The various spam plugins I have caught the vast majority, but that still left a few dozen a day for me to review.

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.

Recently on the perl5-porters list, there have been several discussions about backwards compatibility and the future of Perl 5.

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'm going to be in Chicago for Chicago VeganMania on Saturday, November 5. I'll be arriving late afternoon on Thursday, November 3, and leaving in the afternoon on Sunday, November 6.

I'll be pretty busy, so I can't promise to get together with everyone or anyone, but ping me via email if you want to get together and I'll get back to you once I have a better sense of my schedule.

I won't be at PPW this year, and thus the Moose class won't be happening. I apologize to anyone who signed up for the Moose class, though last I heard that was just one person, which is the main reason the class isn't happening.

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.

Back in March, I mentioned that I was working on a new OO tutorial for the Perl 5 core. I've been working this intermittently over the last eight months or so, with lots of useful feedback from the perl5-porters. Along the way, the project grew to include a rewrite of the perlobj document, the reference document for Perl OO.

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.