On May 1st I learned what happens if you tell a bunch of people on the Internet, not all of whom you've met before, that you're going to teach Perl (5 and 6) for free on an IRC channel for four hours.

It worked well. Actually, it worked well beyond my expectations.

Successes

• Prepare. I had written a bunch of material; short-ish texts mixed with exercises. I didn't hear any feedback about the texts, but people threw themselves on the exercises. Which was lucky, because I basically didn't have time to interact much with people. Everyone did their own thing.

• Map. The week before the workshop, I was taking a walk, and it occurred to me that the topics for the workshop should be laid out on a subway map. That turned out to work unexpectedly well. People followed the structure, I think. The material was pretty clear that they were free to skip/jump around if they wanted, so some did that.

• Github. People suggested fixes and improvements to the material during the workshop. I handled the easy ones, and delegated what could be delegated. If anything about the workshop felt 2013-futuristic, it was the fact that participants were hacking on the workshop in real time, as it was being played out. Github was totally right for this.

  • tadzik++ did an exercise and got a solution that I didn't expect. We agreed that a test was missing to force people to do the right thing, so he went ahead and added it.
  • LlamaRider++ added hyperlinks between all the files.
  • grtodd++ made the subway map clickable.
  • choroba++ added hyperlinks to a file that I added later.

Things learned

• Newbies. This was never a workshop for total beginners. Still, we got a number of those. I'm not sure how many. If there's a next time, I'll want to add a track for the people who haven't done Perl before.

• Exercises. Based on the tasks that people actually solved, I got a lot of feedback on what worked and what didn't. Which exercises served the overall message of the course, and which ones didn't.

• Message. After the workshop, I know much better what I wanted the whole thing to be about. I think I can go back and make that even more clear. I'm still surprised at how well it worked already the first time around... but some bits in there can certainly be improved.

Message

So... what was the real message of the workshop? What is "masakism"?

Two things:

• Testing gets you far.
  • My pain threshold for writing things without tests is half a screen of code. If I have more than that, there's probably something I should be writing tests for.
  • That said, there's no need to be a fundamentalist about anything. I'm just saying that tests are good, and still somewhat undervalued sometimes. But it's always a question on spending time testing the stuff that matters. Of course.
  • Even with tests, there's no substitute for knowing what you're doing and where you're going. Tests help a lot, but they don't write the program for you.
• Keep it small and simple.
  • "Inside every big interesting problem is a small interesting problem, struggling to get out."
  • The realization that you can write objects that focus entirely on your core problem, is a strong one.
  • People tend to bring in persistence too early, "polluting" their core classes with database code. Hindering testability. This is backwards.
  • Your program should be like an onion, with the most precious stuff in the middle, and layers around that. Outer layers should point to inner layers, but not vice versa.

Once more?

So, should we do another #masakism workshop?

Yes, maybe we should. People seemed to like this first one. I'm open to finding a datetime for another one.

If you have any suggestions, get in touch.

How time flies. It's two months since I reviewed the first batch of p6cc solutions. I solemnly swear the next blog post will appear sooner than that.

## Generate rectangle haikus

Write a program that generates haikus. A haiku has three lines, where the first
and last lines have five syllables each, and the middle line has seven. For the
purpose of this exercise, each line consists only of letters and spaces.

The haikus generated have the additional requirement that each line be of equal
length. The length requirement should not be gamed in any way, for example by
padding lines with spaces.

    since this one does it
    rectangle plus a haiku
    it serves as fine text

The program should attempt to generate a new haiku each time. The haiku should
consist of English words. If the words make sense in some kind of sentence
structure, that's considered a big bonus. Humor and/or deeper meanings are even
bonuser.

If you attempt to cheat at this task, you will be defeated by people who don't.

You're free to supply your own wordlist. How you count syllables is up to you,
and part of the task. You won't be challenged on trivial differences in
syllable counts.

It's OK for the program to run for a while, but it should preferably terminate
within a reasonable span of time.

I warmly recommend people to check out the solutions to this one. People are all over the place, coming up with ways to generate a rectangular haiku.

Some patterns recur, though. Let's break things down into subtasks and discuss them separately.

Word lists. Some contestants had their wordlists inlined in the code. Others had it in a separate file. Some stored part-of-speech information together with the word, or syllable count.

Sentence structure. Solutions are all across the spectrum, all the way from "just spew words", via "generate something that could perhaps pass for a sentence", all the way to "try really hard to be grammatical". In my view, being more high-end on this bit pays off big in quality. But it also costs in code complexity and program speed.

Search. This is a biggie, because it bleads through into the whole design of the program. Some of the solutions simply brute-force it. Others generate stuff randomly but store things in a hash table, guaranteeing that eventually some triplet of lines will form a haiku of some length. Some algorithms do clever things here, like turning problems around, going from "how many syllables does this line have?" to "ok, give me a word with this many syllables". One solution partitions the integers 5 and 7 in all possible ways, and hard-codes the resulting table.

But the really interesting bit in all solutions is the syllable counting. This is where the participants really differ in approach. One went with porting the CPAN module for counting syllables. Someone else did the same, but put the module on modules.perl6.org for everyone to use. Two contestants seem to have come up with their own (flawed) syllable-counter. A few people evade the syllable-counting by just storing the values along with the word lists. (Which is fine.)

All in all, an interesting set of solutions to a fun problem. Somehow, after reviewing all of these, I have the distinct feeling that a "best" solution could be put together by combining the best bits of everyone's solutions. I might just do that myself, if no-one beats me to it.

Next up: arranging wire crossings to rearrange wires!

So, as part of my $dayjob, I was teaching a Perl course. Then this happened:

* masak is teaching Perl 5 today! :)
<Heather> masak teach me
<masak> Heather: later; these people are paying me. :P
[...]
<masak> seriously though; if there were enough interest here on IRC, I
        would totally do a 1-day Perl 5 IRC workshop, pro bono.
<masak> ditto a one-day Perl 6 IRC workshop.
<vaelxon> (Perl 6 IRC workshop)++
<masak> it'd be very awesome, I promise. I'd need some time to prepare.
        but then we can grab a channel and basically party/learn for a
        day together.

And that's now what's happening. It'll be a loose-knit group of us, joining up in the #masakism IRC channel for four hours on May 1.

The course will be two-pronged; Perl 5 or Perl 6, whatever people prefer.

There will be prepared study material and exercises, but basically, people who participate can go off on a tangent, just spend the four hours solving one of the exercises really well, or solving a different exercise that they make up themselves. People can focus on doing the exercises, or on discussing various ways to solve them, or on discussing general principles of programming. Think of the workshop as a hybrid of people writing/showing nice code, and people discussing programming best practices.

Why am I doing this? Because as part of teaching Perl courses for $dayjob, I realized how much I love teaching Perl. I literally spend those two course days teaching Perl in a mild state of euphoria. I teach a lot of other courses, and some of them are great to teach, but none of them are like Perl. I think it's because I feel at home in the language, my brain has somehow "shaped itself" around Perl, and the questions I get can often be answered with a happy "let's find out!" where (a) we do some quick experiment in a terminal window, and (b) I tend to know what we'll get before, so it's easy to explain.

The whipuptitude of Perl really works to one's advantage there. That, combined with knowing my way around most of the perldoc pages and most of the special variables. Oh, and I probably have a slight advantage being fairly deeply involved in Perl 6 stuff, too.

Anyway, I absolutely love teaching Perl. Five and six. So much so that I'd do it for free. So this is me doing it for free.

As I write this, there are 13 participants signed up for the course. This is already twice as big as the typical Perl course I teach in a corporate setting. It's also a wide range of people; from relative newbies to people who could probably give the workshop better than me. I expect people further up on the learning curve to step in and assist with people further down. But I hardly need to say that; this is Perl, and we're a helpful bunch.

Here's more info about the workshop, including when, where, what, and how to sign up.