Here's what I wrote in another post earlier this year:

[...] what makes me the most optimistic about the Perl 6 effort: after a few years of watching things evolve, I've noticed that while Perl 6 is being developed top-down on the outermost scale, it's actually a series of bottom-up projects that drive Perl 6 forwards.

Over the years, Perl 6 users have seen a descending sequence of components being replaced and improved, each one furthering our reach. It reads almost like a nursery rhyme, though with a positive spin:

• When we had junctions, we got ourselves a method dispatch that served them better.
• When we had method dispatch, we got ourselves an object system that served it better.
• When we had an object system, we got ourselves 6model that served it better.

And people have been talking about taking the obvious next step with this: building a runtime, or retrofitting an existing runtime, that would serve 6model better.

Today MoarVM is revealed. It's a VM for 6model.

Imagine taking all the lessons learned about Perl 6 and VMs, and factoring them into a project like this. jnthn's article goes on to list all the things that MoarVM does:

• lightweight and focused
• quick and easy build
• JIT compilation (to be explored in the future)

The really nice aspects of this can be read between the lines: MoarVM is lightweight, so it starts up faster than the JVM, and even before the real optimization and JIT work begins, its runtime performance already shows some promise.

There's no historical baggage, and there's not a sense that the project is fighting technical debt when moving forward. Since MoarVM is designed for nqp from day one — in a very real sense, MoarVM is an nqp backend — we're guaranteed both a nice direct focus on Rakudo, as well as the ability to support other higher-level languages long-term. Things are factored in a way that we can build Perl 6 on. Hard-earned VM lessons from 2001 up until today are coded into the foundation.

In other words, MoarVM reboots the whole VM idea for Perl, based on experience with Parrot, without many of the flaws of Parrot.

Of course, work is still very much ongoing on other backends as well. With nqp bootstrapped on the JVM, about to be bootstrapped on MoarVM, and likely running on JavaScript soon, we're looking at a very interesting 2013.

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!