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:
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.
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.
You may recall that my mentioning that my favorite talk at this year’s YAPC was Sawyer X’s “The Joy in What We Do”. If you remember (or click one of these links I keep throwing at you), long about 26:28 Sawyer X makes a radical suggestion: if you want to release an application which uses Perl, maybe you shouldn’t be releasing it via CPAN. I mean, CPAN is awesome for modules, and it’s not too shoddy for Perl apps either. It makes it very easy to install for people who already have Perl, and know how to operate the CPAN shell, or
cpanm, and either have root access on their machine or are already using
plenv, and ... In other words, other Perl programmers. And, if that’s your audience, then lovely. Although, even then ... what if you need a particular version of Perl, and particular versions of certain modules? It’s all doable, certainly, and even moderately easy for Perl’ers of a certain experience level. But why should we limit ourselves unnecessarily?
What Sawyer X points out is that we have the technology: we have
cpanm, and so on and so forth. We have ways to bundle everything you need to run a given Perl app, from the precise version of Perl to the preceise version of every dependency module, all in one place, without giving a royal shit what version of system Perl someone has, or what version of this or that module they have, or whether they can install modules or not (either because of access issues or inexperience), or any of that. We have all the pieces. We just need to put them together.
[Pleased as I was to get mentioned in a lightning talk in this year’s YAPC, I noted that my mention was in the context of writing blog posts that “don’t contain much code.”1 Well, fair enough: I’m a verbose bugger, and a wannabe writer, so my prose does tend to ramble. But I can do code, dammit. So, you know ... here’s some code.]
The other day I was working on my music library scripts,2 and I needed a menu for something. Now, there are oodles and oodles of modules on CPAN to help you write menus. I’ve looked at most of them, and tried quite a few, but long ago I settled on using the
-menu option in IO::Prompter, by the Damian. For a nice, pretty menu layout—say, something you do as a central feature for a program—it’s tough to beat. It’s not perfect, by any stretch, but it offers some very nice features, such as (optionally) not requiring
ENTER after a menu choice.
But that’s not what I wanted in this case. What I was looking for here was a quick, compact menu ... sort of like what you get when you’re interactively staging a commit in
git (that is,
git add -p, or, probably more commonly,
git add -i then choose “patch”). Specifically, the features I wanted were:
Not specifically about Perl, but I did write a post this week about the software development business in general over on my Other Blog. Might be worth checking out if you want to listen to me ramble on for a bit on that topic.