Modern Perl Programming

A few days ago, one of Perl's most distinguished free-floating agents of chaos posted a patch for discussion. dots.pm changes the Perl 5 dereference arrow to a dot. This lexically scoped pragma also changes the concatenation operator from dot to tilde, which is the current syntax in Perl 6.

p5p reception tended to be positive. Discussion elsewhere tended to be negative. After reviewing the proposal and reception, Perl 5 pumpking rjbs rejected the patch for 5.20. His reasoning is straightforward. While fans of dots.pm may feel a legitimate disappointment at the current rejection of the patch, it's worth praising rjbs for an evenhanded evaluation of the intent and implementation of the feature. (If that evaluation had gone into the smartmatch operator or automatic dereferencing of references to aggregates with each, for example, Perl 5 would be in better shape.)

My initial reaction to the patch was mild interest. It didn't immediately grab me as an idea that Perl needs. The more I thought about it, the less I liked it, for four reasons.

The other day, I found myself with the perfect example to explain continuations to some web programmers I know. (If you didn't already know how continuations can make you sandwiches without you leaving your office, they're powerful things.

Imagine you have a controller for a web application. Imagine one of the methods is edit_profile. You have an access control mechanism that requires authentication before someone can edit a profile. Your code might look something like:

sub edit_profile {
    my ($self, $request) = @_;

    return $self->redirect_to_login_and_return( $request )
        unless $request->is_authenticated;

    # actually edit the profile here
    ...
}

Now HTTP is stateless. Barring some persistent connection through websockets or the like, the server must redirect the client to an authorization page, receive and verify another request from the client, and, if that succeeds, redirect to the action shown here to complete the user's request. If there's state built up to make this request (a user ID, form parameters, the contents of an active shopping cart, whatever), something needs to manage that data through all of these redirects.

There are plenty of ways to handle this; you've probably implemented at least one. It's a common pattern.

If you're like me, you'd like to be able to set aside the current request temporarily, manage authentication, and then resume the request just after the point of checking for authentication.

In other words, once your web framework has handled the HTTP response to the point of figuring out what the client wants to do (edit a profile), restore the state of the web application and start over as if the client request had been authenticated from the start.

Again, you can do this all manually, but if your language or framework supported continuations, you could have a mechanism to capture all (or some—that's a delimited continuation) of the control flow and request state through your application at the point of checking for authentication and restore the state of that control flow.

There are nuances here. You probably also need to serialize the state of the continuation and HTTP request and store that on your server (never trust the client). You need to collect stale continuations (clients can abandon requests) but not too frequently (you probably have tabs open in a browser window that's been open for days, too). You have to go to some lengths to avoid circular references, and it's not always easy to serialize information like open sockets, open files, and active database connections.

... but these problems are solveable, and if your language and/or web framework supports this (if someone has solved them once and for all so that the average programmer doesn't have to), then you have a powerful tool for managing state atop a stateless protocol.

Note that a web framework could provide this feature even when its host language doesn't... but that's an idea for another time.

If programmers could learn one thing from successful businesspeople, they should learn about the idea of opportunity costs. Sure, it's fun to throw away a lot of code and rewrite it from nothing, but in the years you're waiting for that mystical magical super sixy project to get usable, you could have been making money with working code, even if it's a little shabby around the edges.

Sometimes opportunity cost works the other way, too. If you can get a 1% return by putting your money in a CD for 12 months or you have the chance to get a 10% return if you can buy the right stock sometime in the next three months, hold out for the 10% return. You might get it. You might not. Yet the reward is greater than the risk.

So it goes with programming.

When I wear my programmer hat, I want to write the best code imaginable. I want to find the right abstractions. I want to discover the most elegant design. I want to put in the least effort. The risk of getting it wrong and having to do more work is greater than the risk of missing a deadline.

When I wear my business hat, I want the most valuable features as soon as possible. The risk of missing out on business value (greater revenue, lesser costs, greater productivity) is greater than the risk of increased future maintenance costs. After all, it should be possible to measure those increased costs and deal with them when it makes the most sense from the business point of view.

Project management includes the art of navigating between the business desire to have working software sooner and the programmer desire to have elegant software. That's not easy, but there are ways to give both groups some of what they need.

Sadly, community-driven development of the free and open source software worlds often lacks this management. We don't lack the tension though. Consider, for example, the debate over whether it's acceptable to release software without documentation. The business argument is "It can provide value to people." The developer argument is "It's not finished without documentation."

This tendency matters less in the F/OSS world as in the business world where your paycheck depends on your ability to deliver working software. What's the worst that can happen? People will move on to a competing project which better meets their needs. (And you thought F/OSS people didn't understand capitalism.) So you annoy your users and drive them away; you're a volunteer, and there are always plenty of volunteers.

... until there aren't.

Sure, that's an extreme position. Though it's easy to trawl through GitHub (and before that, SourceForge) to find the abandoned carcasses of projects which never delivered anything of value to anyone and consequently never attracted sustainable development beyond the whims of the originators, I suspect that it's more interesting to consider the quiet desperation of active projects stuck in not-invented-here rewrite limbo which struggle to achieve usefulness.

What if they spent more time focusing on the value their code should provide to potential users and less time constructing elegant, airy edifices?

It's important to write clean and maintainable code. It's important to focus on quality and craft. Yes, please let us do that. Yet if you want to have real users, shouldn't you also consider how your choices affect them and what that costs them?

The Perl 5 Porters list is discussing a proposal to remove CGI.pm from the core distribution. Per the discussion, this proposal is likely to succeed, and Perl 5.20 (released around May 2014) will no longer include CGI.pm as a core library.

The arguments in favor of this are:

• It's not great code: it does far too much (conflating HTML generation with parameter processing and cookie handling), its interface is confusing (the kind of halfhearted pseudo-OO that Perl 5 circa 1994 encouraged), and its implementation is weird beyond that (the last time I looked, it had a strange load-on-demand system to avoid the performance penalty of compiling a couple of thousand lines of Perl 5 code).
• It operates at too low a level: you need to understand far too much about how the CGI protocol works to use it effectively.
• Its execution model represents the lowest common denominator of web deployment; it hasn't moved much on beyond 1998 (with some code to support FastCGI and mod_perl, but not much else).
• It's harder to deploy that it seems, if you count the system administration work it takes to configure a web server for the CGI protocol.
• In almost every case, at least one of several plausible Perl web frameworks is a better choice.

The biggest criticism is actually a Perl success story. PSGI and Plack make developing and deploying Perl web programs so much easier that there's no credible reason to use raw CGI anymore, at least if you can install Plack or use a PSGI-compatible library. If you're tied to the CGI approach, Plack::Handler::CGI is a better alternative in every way, even for local development and testing.

The cons of ejecting CGI are:

• It's been in the core approximately forever.
• Sometimes it's the only thing available, if you're using a shared hosting account where you can't install CPAN modules and a bearded sysadmin somewhere refuses to install them for you.

In other words, the discussion on p5p seems to be that the burden of maintaining code that no one uses, no one likes, and no one really wants to maintain in the core is greater than the benefit of providing a mediocre out of the box CPAN-free experience to people who don't maintain their own Perl installations.

In other words, the dominant philosophy seems to be "CPAN is integral to the desired experience of Perl 5".

(I suspect that the CPAN-hostile environment which still promotes CGI.pm as the state of the art in Perl overlaps strongly with the older-is-better-stability-over-all enterprise Linux distribution group, of which Red Hat for example won't provide Perl 5.20 for several years, so the dominant web programming model of 1997 has yet another stay of execution. Hooray. Please feel free to join us in the 21st century sometime.)

The YAPC North America Perl Conferences of the past couple of years have held an event I like quite a bit. It's the first time attendees mixer.

As of a couple of years ago, YAPC::NA organizers and attendees realized that about half of the attendees of each conference had never attended a YAPC before. That's between one and two hundred people whose main face to face involvement with the larger Perl community may have been limited to a local Perl Mongers meeting. Yes, these attendees have almost certainly used the CPAN, very likely participated in a discussion on a Perl web site, mostly used a Perl mailing list (and not just the YAPC mailing list), and have probably been on a Perl IRC channel, but they probably aren't the people you think of when you think "Who are the best connected people in the Perl community?"

As far back as I can remember (which, admittedly, is one of the YAPC::NAs in Chicago), an early morning talk has served as an introduction to YAPC, specifically intended to help new attendees understand the conference and its quirks and norms. That talk invites these attendees to the novice welcome meeting.

The organizers also grab as many of the well connected people in the community—pumpkings, core developers, CPAN contributors, authors, project leaders, anyone whose name you might recognize—and ask them to show up and be willing to talk to people. That's it.

What I like about this system is that it welcomes people in two ways. First, it acknowledges that it's okay to be new to YAPC or the Perl community in person. If that's you, you're not alone. Half of everyone you're going to see at the conference is like you in that sense.

Not only that, but you have permission to participate. You're welcome to attend this little meetup that has an explicit place in the schedule—it's an official part of the conference—and you're encouraged to talk to people you might know only by reputation. They're there to meet and talk to you. They're not there to hang out in little groups by themselves. They're there to talk to you.

I've heard good things about this event. I've enjoyed it every time I've gone. (As an introvert myself, I like having permission to talk to people with a limit of a couple of hours.)

I feel the same way about a YAPC Code of Conduct. I don't see it as a warning that "straying from a straight and narrow path of arbitrariness will not be tolerated, so if you're not sure if you might accidentally say or do something someone else doesn't like, stay away!" I see it as giving people who aren't necessarily well versed in the norms and ideals and messy politics of dealing with the Perl community every day virtually and in person permission to believe that they should feel welcome and important in the community.

It's about empathy.

I understand people disagree about the wording and even need for a code of conduct, and I don't mean to suggest that such concerns come from robots who lack empathy. By no means.

Yet put yourself in the shoes of someone who feels like he might not quite fit in in a talk, because it's full of inside jokes and jargon and the kinds of comfortable banter you only get after you've idled on a handful of Perl IRC channels for months or years. (Imagine that person's an introvert, or at least not as stubborn as I am.) Now imagine the speaker or someone else says or does something that reminds that person that he doesn't belong there, that he doesn't fit in, that he's different.

That's not necessarily assault. That's not necessarily a criminal act. But it's probably unnecessary and hopefully unintentional.

(The best silly example I can come up with is a speaker saying "... and of course, if you're a Windows user, no one cares about you until you man up and get a real operating system." and half of the audience laughs.)

Sure, there are good legal reasons to have a code of conduct that suggests that criminal activities such as assault, battery, and sexual assault are intolerable. There's no gray area about groping or rape or physical violence.

I agree with a lot of Open source is not a war zone, and I agree fully that the Perl community is all the richer for contributions of people like Wendy and Liz and Karen and Su-Shee et cetera. I'm glad they participate, just like I'm glad people like Tim Bunce and Schwern and brian d foy and Dave Rolsky and Rik et cetera participate.

I just can't quite agree that a code of conduct has a chilling effect that will exclude people. I don't see it.

Maybe that's because I see the code of conduct as explicitly saying "If you feel like you don't quite fit in, that's okay. You're welcome here. We take you seriously. If you have one of these big problems—even if it's with a speaker or writer or developer with a famous name—we'll take that seriously. The rules apply to everyone."

Sure, there's more to helping newcomers feel welcome than enforcing a policy of civil conduct, but that's the minimum I want to see, and I'm glad that YAPCs have done other things (less controversial, I'm sure) to that end.