use Perl

I had a better connection to the wireless network during the Higher-Order Perl tutorial. So I took the opportunity to join the #oscon channel on both Freenode and irc.perl.org. I always find it slightly weird to chat with a group of people in the same room, but completely unidentifiable to me.

In those very channels, a group of us decided to head over to the Rogue Ales Public House for some beer and some grub. Somehow I was elected the unofficial guide of the group (perhaps because I was the only one who couldn't point a finger fast enough) and we were off. After a brief MAX ride and a brisk 14 block walk, we sat down to some fine ales.

I savored a glass of the Imperial IPA before bowing out early to attend the special Portland Perl Mongers meeting back at the convention center.

I have been interested in higher-order Perl ever since the book of that title was released. While I've not read it, and I only intermittently follow the mailing list, what higher-order Perl represents fascinates me. That said, I'm a little disappointed that I opted for Mark Jason Dominus's tutorial on higher-order Perl rather than, say, Damian Conway's tutorial on Vim. Not to say that I found Mark uninteresting or uninformative. Quite the opposite, in fact. Unfortunately, most of the tutorial was below my skill level.

Having earned a degree in computer science, topics such as caching, memoization, iterators, and lexers are familiar to me. What I did find interesting, however, was Mark's application of Perl to these concepts.

Here is a language I have been using for over ten years. I consider myself an expert at using it. Even so, there is always some new trick or some new way of looking at things that I can learn and then apply to my own programs.

Coding in higher-order Perl, as it were, is coding with an entirely new set of ideas about how to program. The underlying theme of this tutorialaside from closures, closures, closures, baked beans, and closureswas the use of open systems as building blocks. By starting small and simple, the subroutines are easy to design. By staying open and flexible, the subroutines can be used like Lego blocks to construct even the most massively complex system.

I might have come to OSCON if it had been called DamianConwayCon (DCCON? ConCon?). He is, quite frankly, an amazing speaker. It is possible that I hold a bias for his usual subject matter, but I have met non-Perl-mongers who tout him as one of the best technical speakers.

Having received the contents of Damian's slides, I didn't expect I'd take any notes, but I fired up a Vim instance anyway. By the end of the tutorial, I had taken nearly 200 lines of notes. This is the second time I have attended one of Damian's presentations. It seems I always leave brimming with ideas for my own projects.

I found that I already apply many of the seven principles Damian put forth as being the root of better API design. There were many moments, however, when I would stop and think, "Gee, why haven't I been doing that all this time?"

These best practices always seem obvious in retrospect, but it certainly helps (and saves time) having someone point it out with big, neon, flashing lights.

Exploring the waterfront this evening, I found an interesting barge moored near the convention center. Coincidence? I'm not sure.

My fellow Perl Mongers convinced me to attend OSCON 2006. So, after convincing Qualcomm to send me, here I am in Portland, Oregon. Tomorrow morning OSCON gets started with the tutorials and, as one might guess, I will be following the Perl track.

Should be an exciting week. I'll be updating my journal as time permits.