[...] 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.
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.
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!