Option configuration is a classic example of when I prefer a purely functional approach. This post is not about broken semantics, but rather about the tension between ease of implementation and ease of use. Given Perl's imperative heritage, many modules default to imperative option specification. This means that the choice of one behavior over another is represented by an action (setting the optio

<record type="broken">I'm a big fan of purely functional programming</record>. Another reason I like it so much is that purely functional software tends to be more reliable. Joe Armstrong of Erlang fame makes that point in an excellent talk much better than I could ever hope to. However, one aspect he doesn't really highlight is that reliability is not only good for keeping your system running, it

The one thing that I almost always notice when playing around in non Perl languages is how well Perl handles scoping. There is one place in which Perl got it totally wrong though. The value of the current package is lexically scoped: package Foo; { package Bar; say __PACKAGE__; # prints Bar } say __PACKAGE__; # prints Foo However, the notion of the current package during compilation is dynamically

I've just released Sub::Call::Tail which allows for a much more natural tail call syntax than Perl's goto built in. It provides a tail keyword that modifies normal invocations to behave like goto &sub, without needing the ugly @_ manipulation. Instead of this horrible kludge: @_ = ( $foo, $bar ); goto &foo; You can now write: tail foo($foo, $bar); And much more importantly this method call emulati

I spent most of today and yesterday bikeshedding event driven PSGI with miyagawa on #http-engine. We seem to have converged on something that is both fairly portable to different event driven implementations, without being too yucky for blocking backends. For example, if you don't yet know the response code or headers and are waiting on some other event driven thing, it's sort of like continuation

Perl has a very confusing set of behaviors for treating filehandles as objects. ADHD Summary Globs which contain open handles can be treated as objects, even if though they aren't blessed. Always load IO::Handle and FileHandle, to allow the method syntax. Whenever you are using filehandles, use the method syntax, regardless of whether it's a real handle or a fake one. A fake handle that works with

My friend miyagawa has been championing PSGI and its reference implementation, Plack. This is something we've needed for a long time: a clean and simple way to respond to HTTP requests without the cruft of CGI and %ENV. The PSGI specification requires the body of the response to be represented using an object similar to IO::Handle. I've released IO::Handle::Util, a convenience package designed to

I'd like to thank to everyone that made my trip to Asia so great thus far. To list but a few: thanks to the JPA for organizing YAPC::Asia, especially Daisuke for being so accommodating when it wasn't clear if I would make it till the end, gugod for organizing YAPC::Tiny, Kenichi Ishigaki and Kato Atsushi for translating my talks (though only one was presented in the end), clkao and audreyt for bei

During the YAPC::Asia::2009 hackathon I refactored a bunch of XS modules out of some other code, both rafl's and mine. XS::Object::Magic This module provides an alternative to the standard T_PTROBJ approach to creating C struct based objects in Perl. The traditional way creates a blessed scalar reference, which contains an integer value that is cast to a pointer of the right type. This is problema

It's well known that while Moose competes well with hand written code at runtime. However, Moose code still needs to pay a lot at compile time, due to the comprehensive extensibility of the metamodel. We've previously made fairly successful attempts to optimize startup but there's always room for improvement. Thankfully Goro Fuji has received sponsorship to optimize Moose's startup time, and even

Perl's reference counting memory management has some advantages, but it's easy to get cycle management subtly wrong, causing memory and resource leaks that are often hard to find. If you know you've got a leak and you've narrowed it down then Devel::Cycle can be used to make sense out of things, and Test::Memory::Cycle makes it very easy to integrate this into unit tests. Harder to find leaks are

Using KiokuDB with Catalyst is very easy. This article sums up a few lessons learned from the last several apps we've developed at my workplace, and introduces the modules we refactored out of them. Let's write an app is called Kitten::Friend, in which kittens partake in a social network and upload pictures of vases they've broken. We generally follow these rules for organizing our code: Catalyst