use Perl

When I said I'm not forgetting Perl I meant it. Allison and I have been adding Perl content to OSCON, so if you haven't checked out the schedule lately then you should give it a gander.

We've got Pudge on porting Mac::Carbon to Intel, building Search applications, Live Perl Testing, and the amazing Audrey Tang on the mindbending stuff she's been hacking on. And if you missed Miyagawa's plagger talk at YAPC, check it out at OSCON. It was hilarious in that "this is so evil it's good" way. There's more Perl in other tracks (e.g., Ingy).

Me, I can't wait for the lightning talks. I'm so eager I'm already in Portland--well, actually, I'm here because I've nowhere else to be until OSCON (fly over the Pacific for two weeks? No thanks!) and so I'm getting to enjoy the city instead of flying in, conferencing like a mad bastard all week, then flying out. In Portland? Want to have lunch? Ping me at gnat \N{A WITH CIRCLE AROUND IT COMMONLY KNOWN AS AT} oreilly.com .

I'm so late to the game--matts and others were all playing with Ruby years ago, while I was just scheduling talks on it at OSCON. Now I'm finally getting my feet wet (ok, I'm jumping right in) and it's a blast. My guide: Ruby for Rails by David A. Black. He teaches Ruby a lot like I taught Perl--I keep finding echoes of my Perl classes in his explanations of references, closures, and so on.

As for Ruby, well it's true: it's like Perl only easier. I've been working on my coding chops, which have atrophied after several years of pencil pushing mindlessness at O'Reilly, and it feels good to be building up cortical muscle again. The first Ruby program I wrote was a maze solver. It turned into a depth-first search with support code to read mazes from files, turn x's and spaces into data structures, and so on. The learning curve here was realizing that when I was trying to do something complex and possibly impossible (pass to a function a reference to an accessor method) I should instead look at my code and figure out a better representation or implementation. I did, and lo! the code was simplified to the point where that messiness was no longer necessary.

The second program solved a problem from Dr Ecco's Cyberpuzzles: partition the integers 1-52 inclusive into four buckets such that no three integers satisfying a+b=c are in the same bucket. Again with the depth-first search (it's bringing home with emphasis why my AI prof seemed to use the term "search" synonymously with "AI") but this time I got an elegant representation of the problem, which made the implementation much easier. It's a great example of the rapid growth of the problem space: it's a nigh-instantaneous solution up to 40 integers, but give it 50 and suddenly it's taking tens of seconds to find the solution.

My current program is finding an Eulerian circuit in a graph. It's the Bridges of Königsburg problem: cross all the bridges exactly once. The mathematician Euler showed that it was impossible for the town of Königsburg, but a mathematician Fleury came up with the algorithm for finding the path if there is one. So I'm now writing Node and Edge classes with which to implement the algorithm, and again as I get more into the mindset, the more quickly the code comes. However, I've been sidetracked by reading up on the possible ways to implement graphs (adjacency matrices, etc.), which took me to eigenvalues and flashbacks to the Linear Algebra class I dropped in my second year at university, and .... well, you get the picture.

Anyway, I'm loving Ruby as much as I'm loving stretching my brain. What do I love about it? It has all the stuff that's missing from stock Perl (slurping in a file is trivial, as are filtering and reducing an array and several dozen other basic operations) and its basic premise that everything's an object makes it very easy to figure out what I should be doing to solve a particular problem. I'm not abandoning Perl (I began the rehabilitation of my brain by reading Wikipedia's description of quicksort and then implementing it in Perl) but I'm enjoying exercising my brain by learning new oddities (e.g., closures) and contorting my powers of expression in new ways. In short, I'm having fun doing something at the keyboard that isn't email.

I've long been curious about how to extract information from images with computers. In particular, I want to stick a camera at the top of my driveway and capture the license plates of the thoughtless buggers who roar up the road when the rest of us are in bed. But to get to there, I first need to know how to arse with images.

So I've really enjoyed reading this course in computer vision. No huge pages of code. The math isn't that daunting and can be easily skimmed if you're reading for an overview. Interestingly, it appears to have been written for UNESCO by someone in Vietnam (there are other courses. I love the internets.

--Nat

While packing I just found a proof sheet for the little business cards I made for a San Diego OSCON around the turn of the millennium. Eight phrases, each preceded by the word "Perl" on a line by itself, and followed by the URL http://www.perl.org/. For your historical pleasure, here they are:

• If I was your manager, I'd fire your ass and replace you with twenty lines of Perl.
• It's what the kid who replaces your department will code in.
• It's like Java and C++ and C#, only it doesn't suck ass.
• It's like Java, only it lets you deliver on time and under budget.
• Because life's too short to code without interpolation.
• Go ahead, use Java. That just leaves more punctuation for us real programmers.
• Because Java can kiss my ass.
• When the best is good enough.

Ah, tempestuous youth. I distributed several hundred them around the tables of the speaker room over the course of the conference, and not one person smacked me.

--Nat

Perl

"Learning Curves" sounds like the title of the O'Reilly beginner's guide to soft porn, but that's not what this is about. I'm writing my first Python program. It is quite the adventure, and I'm learning a lot about learning (always good).

Things I have learned include, in no particular order:

• Learning Python and Programming Python aren't what I expected them to be. They're not the direct translation of their Perl equivalents. This goes double for the Python Cookbook , which seems to assume you already know everything in the standard library and so only covers stuff outside the standard library. I lost a non-trivial amount of time trying to find the StringIO class. Apparently Python in the Nutshell is the book I should be looking for.
• Working sample code is real important in documentation. It's not ubiquitous in the Python documentation, which gave me grief. And when it is there, sometimes it's misleading. For example:

  f = StringIO()

  won't work. You need to use StringIO.StringIO() or you get a message about not being able to call a class as function. Twitch, twitch. Fortunately, the nice people on #python were able to set me straight.

• Python has different behaviour for compile- and run-time binding of names to code. There is no compile-time binding of function names to code. The Python equivalent of sub foo {} is identical to *foo = sub {}. There's no compile-time binding of function names to code, so you can't call a subroutine until the subroutine definition has been "executed". This tripped me up ("what do you mean the function isn't defined! It's right bloody there!"). Again, #python to the rescue.
• CPAN is fantastic. Not that Python doesn't have amazing libraries, it does. But the one-step CPAN shell is just a treat. As much as I've been cursing it as I drag in 3/4 of CPAN just to build one of Jesse's modules, it's a damn sight better than having to download and install each module by hand from a separate location .... I'd hate to do something big. I wonder how widespread is the use of Activestate's Python Package Manager.
• Indentation versus curlies is, as I'd long suspected, a bogus issue. You lose a little context when you close many blocks at once (without lines of close curlies, it can be hard to tell whether that's three or four blocks being closed) but that's not as big a problem in practice as I'd thought.

It's been fun to do something new, though I'd have found it quicker to just port the library I wanted (the Universal Feed Parser) to Perl than to learn the Python I need around that library. That's okay, I'm doing this to learn another language and not to get the job done in the shortest possible time.

--Nat

Yes yes, Ziggy, it's not a competition, but even in a friendly race it's nice not to come last.

--Nat

I'll have been gone pretty much every other week of the first quarter of this year:

• Jan 10th: speaker training, MacWorld, IBM Almaden.
• Jan 30th: OSDL Linux Summit in San Francisco, then a bunch of companies around the new conference.
• Feb 8th: VSLive in San Francisco, speaking on open source and patents.
• Feb 15th: LinuxWorld in Boston.
• Feb 28th: EclipseCon in San Francisco.
• Mar 13th: ETech in San Diego.

I've been resisting more trips, but I think there might be a European conference trip in my future. One reason for all the travel is to build relationships with people so that I can move back to New Zealand and still be effective in the job.

Yup, I've finally convinced Jenine (or, rather, the election finally convinced Jenine :-) to move to New Zealand. It's all butterflies and suppressed fears at the moment (will we make friends? will our kids enjoy school there? will it ever stop raining?) but I think we're all ready for a slower pace of life. I've told my bosses my plans to move, and so far they've made no noises about it not working for them, so I'm going to attempt to continue doing my conferences job from home in New Zealand instead of from home in Colorado.

If it doesn't work out, who knows--I might yet do open source conferences in New Zealand! I'm sure you'd hate to be an invited speaker to the land of Hobbits and Kong :-)

--Nat

--Nat

--Nat

--Nat