return void;

Today we held the first Perl 6 mini-hackathon. Ironically, there was another Perl 6 hackathon happening in California. A few problems cropped up but the end result was a positive experience. I’ve never been to or held such an event, so I wasn’t sure what to expect.

First, the location we chose, Borders changed their wifi system. Since Seattle’s Best is owned by Starbucks, they switch to the T-Mobile non-free service. We ended up moving next door to Market Street, the location of our usual Perl 6 Mongers meetings. Unfortunately, this location is much louder than Borders, but we made it work.

Then one of the attendees was unable to connect to the wireless network. We ended up spending about 30 minutes trying to help out but ended up having move on. Next time, I will make sure to bring Rakudo and Parrot on a flash drive.

fRew and I set up a fresh Rakudo build. I ran the spectest and subsequently, it crashed my machine. Yeah, it locked up my machine and I had to reboot it when I got home (remotely logged in to my desktop development system). I couldn’t find anything in my system’s logs and the test suite was run in parallel. It seemed to stop spitting out output while it was working on S05-named-chars.

Eventually, it was just Patrick and I. We came up with a system for labeling RT tickets that should be relatively quick fixes. First, you have to filter out tickets assigned to Jonathan; these are typically more difficult issues to fix. Then we decided that we would tag the tickets “LHF” to mean Low Hanging Fruit. For now, you can find “[LHF]” in the subject but we will eventually have a tag created similar to the tests-needed tag.

All and all it was lots of fun. Next time, I will make sure to have an install CD or two, Rakudo and Parrot on a thumbdrive, and find a quieter location with wifi. Next time, we’ll hopefully be able to spend more time working on the LHF tickets.

The next event will be next month, two weeks after the Dallas.p6m meeting. The next Dallas.p6m meeting is slated for September 9th and the next Mini Hackathon is slated for September 26th. We need to setup our website and a calendar.

Just after I had been through a bit of a posting slump due to some fading tuits, it would seem as if they have magically returned. This week brings the start of the Fall 2009 semester and I have seemingly sprung back to life. With the new semester comes new opportunities to use perl!

First, I wanted to mention the one bit of news that made my summer, maybe even the last 2 years, seem as if I haven’t been running in circles. I noticed that my new department head at the university posted the final new rules regarding the qualification exams. The change is that there is a list of approved courses that will be offering the QE, passing any 3 is sufficient, and there is still no marginal grade. The last exam I took, Data / Text Mining in Bioinformatics, was not listed in the blessed course list. Turns out, the department would still accept the score, so I now only lack 1 remaining pass to be an official “phd candidate“.

This semester I am taking the Design & Analysis of Computer Algorithms course. The down side is this course tends to be theory-centric, so I won’t have many chances to flex my Perl muscles. There are tons of modules on CPAN though that might help understanding the basics. There are plenty of graph, tree, and dynamic programming solutions available.

Interestingly enough, while sifting though those modules, I discovered a module of personal interest. I stumbled across the Algorithm::Viterbi module. I have studied Markov models, Markov chains, and Hidden Markov models a bunch in the last 2 years. One algorithm that keeps showing up is the Viterbi algorithm. I’ll leave it as an exercise to the reader as to how this algorithm is used, but I will point out that the Wikipedia page has Python code. Ironically, “Python’s answer to CPAN” isn’t quite all it’s cracked up to be; it lacks any packages pertaining to “viterbi” and no generic Markov package.

Perl: Automatically tested, student approved.

I have been postponing this week’s Perl post mostly because our monthly Perl 6 Mongers meeting was yesterday. I brought up and did some initial planning for a monthly Rakudo / Perl 6 mini hackathon. I have an outline of events but I want to discuss the Dallas.p6m meeting briefly first.

fRew was going to give a lightning talk about Perl 6′s object model but had to postpone due to a lack of preparation. We are all getting to know each other well and the conversations covered the spectrum: from Guido’s Simplification Of Choice to Perl 6′s attributes and then finally to processing.org‘s Javascript framework.

Lastly, I brought up the idea of having monthly mini-hackathons. I thought it would be a great way to put Patrick’s talk into practice. So the initial idea is to have a 2-hour hackathon two weeks after the Dallas.p6m (second Tuesday every month), which should be the last Saturday in the month. The first get-together will be focused on Patrick’s talk, with others expanding as people find new areas of interest. That means the first mini-hackathon is slated for August 29th and here’s what I have tenatively planned:

1. Introductions
2. Getting and building Rakudo
3. Running Rakudo
4. Mailing Lists / Ecosystem
5. Understanding RT
6. Test Suite access and explanation
7. Setting

We may or may not be able to cover all of that. Patrick seems confident that we will be able to cover these topics so I am fairly happy with the layout. There will be more details forthcoming about the venue and the time/date.

I’ve never been to or held an event like a mini-hackathon, so I’d love to hear suggestions.

Earlier this week, I was hanging out in the #corehackers channel and I decided to voice my opinion on the flood of discussions concerning the problems plaguing Perl 5. David Golden challenged me to respond to his post concerning what I want from Perl 5 moving forward.

First, my suggestion to chromatic was that new features should receive first class citizenship over deprecations. Since I prescribe to the technology-over-politics philosophy, I think deprecated features should be removed after 2 releases. Once removed, they should be provided within a library. I don’t feel those aging applications depending on these features need to be intentionally broken, but at some point, features that have been deprecated for 10+ years need to be removed. Keeping them only makes the deprecation problem harder every release they remain.

So what would I like to see out of Perl 5 in the future? Perl 5. It’s simple, I just want to see Perl 5 continue to thrive until there is a complete Perl 6 interpreter (it’s been 9 years, may very well be another 9). Frequent releases have the effect of convincing people that there is an active developer community. When application developers feel there is an active community, they are more likely to consider the platform viable. Application developers do not seek dead platforms for The Next Big Thing.

There are many things Perl 5 pumpkings and developers can do to achieve this. Frequent releases are a must; it doesn’t matter if 1 or 1000 tickets were closed since the last release, getting it out the door is the most important thing. Worrying about 100% backwards compatibility in every release means releases don’t happen. Just look at 5.10.1. 18 months for a minor version upgrade? How many pumpkings has 5.10 had anyways? It’s time to move on and to stop worrying about breaking all of DarkPAN.

Features that extend the expressiveness and flexibility of Perl 5 need the highest priority. The grammars in Perl 6 mean that Perl 6 can eventually host Perl 7. That feature alone will keep Perl 6 alive years beyond any other language.

In the end, bickering about release schedules, deprecation policies, dependency problems, or any other issue is not going to get Perl out the door. At the end of the day, there are technical and social issues to work through. Social issues are hard; people don’t change their minds easily. Let’s just agree to solve the technical issues, which are significantly easier. Scheduling releases, fixing segfaults, and updating modules are all just technical problems that all have solutions. They may not be pretty or quick to fix but solutions exist, and in most cases, we already know what’s needed but are too afraid to move forward. Sure, breaking 10 year old Perl 5 scripts will be painful but no where near as painful as watching Perl 5 die a slow and miserable death where everyone involved bad-mouths it until it actually is dead.