Random Perl 6 Thoughts

A number of interesting thoughts flitted through my head when I was out walking this morning. (At least, I hope people find them interesting.) I jotted one line down for each when I got home, and now I'm trying to reconstruct them in full.

There are two major components I'd still like to get into Vector. Yesterday I started trying to figure out how to use postcircumfix to allow users to treat a Vector as is it is an array of coordinates. That is to say, instead of $vector.coordinates[1], you'd say $vector[1]. This is definitely supposed to be possible in Perl 6, but I was utterly unable to get it to work in Rakudo. Of course, I don't know that I was using the proper syntax. I definitely know I didn't understand the examples in the spec. (In my defense, there are no examples of how you'd use this feature in practice there.)

Second, I'm still frustrated by the Rakudobug that prevents you from overloading an operator using code that depends on another version of that operator. My solution of just choosing some Unicode character that gave the impression of standard ASCII character I really wanted to use was enough to get me going, but it offends my sense of elegance. I've decided to prefix the proper ASCII operator with "V" (for Vector) instead for now, which strikes me as slightly better, but still falling short of proper Perl 6. (If only I had another day each week so I could spend some time hacking Rakudo itself, going after this bug would be my first priority...)

Moving on to the bigger picture, I got to wondering if it might be worth having a web page that points to the github repos of the various Perl 6 coding projects going on. As much as anything this was prompted by seeing Moritz's cool post on visualizing match objects and not knowing where I could grab his SVG::MatchDumper code. I know it's probably too soon to have a Perl 6 CPAN, but it's never too soon to make it easy for people to find cool Perl 6 code.

That got me thinking about Masak's Druid project, and how cool it would be to write AI players for that. I've always wanted to try my hand at that sort of thing, but except for some brief and fun attempts in college I've never actually gotten around to it. Of course, not having any clue of workable Druid strategies would make this trickier.

Which made me think how fun it would be to have a Risk game in Perl 6, with hot-plug-able AI players so people could pit their code other's code in battle. I'm presuming there's some way to eval a class from a string, passing the result into a harness which controls that class's interaction with the main game structure....

CPAN Good, Bad, and Ugly

Watching this awesome video Introduction to Catalyst, I was inspired to try it myself.

And that's when the trouble started. It's now three hours later, and I'm still trying to get Catalyst down from CPAN. And I have no confidence I will have a properly working version when it finally does finish installing.

My first attempt to get Catalyst::Runtime and Catalyst::Devel was on my Linux server's default 5.8.x Perl. It ran for maybe fifteen minutes, and then complained that there was something wrong with my distribution's Perl, and I should complain to the distribution packagers.

You know, that might seem like a great way to bring about long term change, but it doesn't seem like the most productive use of my time this morning. So I decided what the heck, let's install 5.10 just to my personal account -- the perfect way to experiment with it without risking blowing up my nice, happy server. (Besides, I've wanted access to 5.10 ever since I started reading the various Perl blogs. Too many goodies to ignore.)

Now this is another positive point -- 5.10 installation was perfectly smooth, even to a non-standard directory. Sweet!

Installing Catalyst took a long time, and came up with the following error:

# You are using perl 5.10.0 with the "Unknown error" bug. This can make #
# developing Catalyst applications much more painful, as it will come   #
# up with no details every time you have a syntax error in a Controller.#
#                                                                       #
# For more information see:                                             #
#                                                                       #
#  * http://rt.perl.org/rt3/Public/Bug/Display.html?id=49472            #
#                                                                       #
# It is highly recommended that you use a different version of perl or  #
# compile a patched version for Catalyst development.                   #

So the link there gives the number of the commit to the Perl source that fixes the bug. But it doesn't provide any obvious way of easily getting that patch. And Perl is in git now, right? I don't see any obvious way of associating that number to a git commit to extract the patch.

So now it's the next day from when I did all that. I have Catalyst installed, and it performed the basic cool step in that tutorial admirably. But I've also got this lingering unfixed bug hanging over my head, too.

And that's the mixed bag of Perl at the moment. On the one hand we have these cool things like Catalyst and Perl 5.10, and that great screencast promoting Catalyst. And on the other hand we have this funky cruft that turns what could be pure awesome into something messy and a bit embarrassing.

I don't have any idea who to blame; I suspect there is a little bit of blame spread out over a large range of not terribly guilty parties. (Including myself -- I'm sure given time I could track down how to get the patch, and put that answer here and/or patch Catalyst to put the answer there.)

But that's my experience with it. Hopefully things will go more smoothly now that Catalyst is installed...

Automagically Generating a Guide

fREW suggests some clever automatic ways to generate a guide to CPAN. Certainly if it can be done well, that is preferable to the inevitable bickering that would result from a non-objective guide!

I did have one additional notion that might help, thought I can't decide if it is crazy or not. What about some sort of opt-in anonymous module usage monitoring, ala Last.fm's scrobbling? It could help figure out which modules are in common use -- imagine doing a CPAN search sorted by usage. It could be another handy stat feeding into an automatically generated guide. It would also allow easy searches for orphaned modules that are in heavy use.

Obviously there are privacy objections, potential speed issues, worries about gaming the system, etc...

Guide to CPAN Needed

I'm all in favor of chromatic's suggestion to dump most of the core Perl modules. But I think he left out what might be the most important (and most controversial?) part of such a plan: providing a proper guide to CPAN.

In a previous post I complained about the difficulty of figuring out what MP3 tagging module to use. CPAN is great at providing alternatives, but not terribly good at providing a way to evaluate the pros and cons of those alternatives.

Now, with something like MP3 tagging that is just an inconvenience. But if it happened to core modules, it would be a disaster for Perl. The best thing about the core modules is you know they are a standard. If you want to do, say, standard file handling, you us IO::File, simply because it is there. But if it's not there, and you're a beginning searching CPAN, you'll be confronted with dozens of modules that sound like they might do the right thing. It's an utter nightmare for the poor beginner who just wants to get his twenty line script running.

It seems to me the answer is a guide to CPAN, something that points out what you should probably use and what you should avoid at all costs. Maybe it should be a web page, or a wiki, or just a standard module package that everyone should install. But something is needed, and it will have to be opinionated to be useful.

PS It is especially needed because you've got to think people will start re-evaluating those basic modules in light of the past ten years' changes to Perl (and the even greater ones coming chromatic envisions). Moose::IO::File anyone?

Lost in the CPAN

A Foolish Manifesto has an interesting post on renaming MP3 files. It's a simple little script, the likes of which I have written several times over the years. Yet I don't recognize any of the modules he is using.

I actually noticed this the last time I tried to write one of these scripts. CPAN has a number of different MP3 tag modules, all in various states of disarray. I know I have used different modules over the years as I coded quick MP3 tag hacks, but the time between these hacks is so long that every time I feel like I'm starting fresh -- with no idea where in the maze to start.

Now fREW reveals a new one I never noticed before, Music::Tag. (Presumably it handles more than just MP3s.) I see it is at version 0.33, and hasn't had a release in over a year, which leads me to suspect it is yet another orphaned tagging module.

Is it possible for the vastness of the CPAN to actually become a disadvantage? It seems to me that if there were only one tag module instead of 5+, that one would be better supported. And it would be a lot easier for a potential user to figure out what to use.