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.
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.
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.
So... what was the real message of the workshop? What is "masakism"?
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.
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.
sheep hide at bad rains
bitterly modest slumber
its star to their rains
-- generated by one of the t2 solutions
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
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
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
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
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
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
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.