Finding Common Ground ... in Both Directions

Last week I formulated an interesting problem in text processing while working on one of my hobbies.  Since I was only able to devote an hour or two here and there, it took me a few days to get the solution up and running, which indicated to me that it wasn’t as simple as I’d thought it would be at first.  And since “not simple” often means “interesting,” I thought I’d share it here with you.  (Note that I don’t claim this is the best solution, or the most efficient, or the most elegant.  I’m perfectly happy to receive suggestions for improvement if you’re so inclined.)

The exact application isn’t important, 1 so let’s just look at the general parameters.  There’s a series of cards, and each card has one or more powers on it (where a “power” in this case just means a block of text).  I have a file with all the powers in it, and a little script to help me search for patterns within and across the powers.  Let’s assume the powers come in, one per line, like so:

Name of Card / Name of Power : Description text of power.

(They’re not actually formatted like that in the file, but I have another script that transforms them into this.)  So my analyze script lets me search for a given regex (Perl-style, natch) and prints a nice summary of the results, like so:2

Breaking the Fourth YAPC

This year I attended my fourth YAPC.  As always, here are my thoughts.  This time around, let’s start with ...

THINGS I LEARNED AT YAPC:

Adventures in Dist::Zilla (among other things)

(Wow, has it really been almost 6 months since I last posted here?  Man, I’m slacking ...)

A while back, I decided to play with Dist::Zilla, and one of the first things I decided to do was make my own plugin bundle.1  Now, if you don’t know what a plugin bundle is ... well, that’s a bit above and beyond the scope of this article.2  Suffice it to say that, if you want to get the most of out DZ, you want to create your own plugin bundle.  (And, if you don’t want to do that, then you probably want to be using something simpler than DZ, like Dist::Milla or Minilla or Zilla::Dist.)

So I created one a long time ago but then I never did much with it.  I personally don’t have enough CPAN distros to juggle to make spending a lot of time fiddling with DZ a priority.  But lately I’ve decided I want to get back into it.  So I started out by installing the latest version I’d put out on CPAN.

Well, trying to install it, anyway.

Kiss Kiss Shebang Shebang

At the end of the discussion, our sysadmin commented:

Perl sure does seem to need a lot of scaffolding these days before one can get around to the business purpose.


And my response was that Perl had always needed a lot of scaffolding.  It’s just that we never used to notice, because it was all built-in.

Pretty much every Perl tutorial is going to tell you that the first line of your first Perl script should look something like this:

#! /usr/bin/perl

Now, sure: it isn’t going to be that easy on Windows, or other non-Unixy systems, and even in the Unices there are going to be flavors where Perl is in /usr/local/bin or somesuch, but that line actually works on a significant majority of the potential cases.  And that’s all you have to do to make your Perl program work.  Perl is a compiled language, but you don’t have to compile your Perl code (which is why it’s commonly considered an interpreted language, even though it’s technically not).  Whenever you run your Perl code, it just magically compiles and runs, including finding all the executable bits and all the libraries and all the modules.  You don’t have to worry about compiling and linking, as you would with C++.  For that matter, you didn’t have to install Perl in the first place, as you might have to do with Python or Ruby.  Nope, everything—all the scaffolding—is just there.

Thoughts on workplace debate

As always, if I make a post about business in general rather than about Perl in particular, I do it on my Other Blog.  As I have done this week.  Check it out, if you’re interested.