Strangely Consistent

Theory, practice, and languages, braided together

Second system syndrome done wrong

I'm mostly happy about the Perl 6 specification. Not all of you may know what it is, so here's a short summary: it consists of several numbered synopses, each of which describes a certain part of Perl 6. Some of the synopses sprang into existence as summaries of correspondingly-numbered "apocalypses" — those are the original Perl 6 design documents written by Larry Wall as a summary of the conclusions of reading through the RFCs. The apocalypses are way out-of-date nowadays; they're littered with updates that alert the reader to how syntax and other things are nowadays, but many of these updates are also out of date. The real specification sits in the synopses; that's where the language is defined.

That's the specification. Several synopses, each of them about some topic. Sometimes STD.pm6 is thrown in as being part of the specification, too, especially as it still contains ideas that haven't made it into the synopses yet.


As different implementations (mostly Rakudo nowadays) catch up with the specification and actually implement it, we become increasingly confident that it actually works as specified. That's code for "we go in and change it a lot until the specification agrees with the implementation". This is a beneficial process, and it's part of why I really like Perl 6: we're not afraid to adjust our dreams to conform with reality.

This back-and-forth between implementations and specification is of course what the in-house term "whirlpool development" is all about. It's a sort of antithetical stance to "waterfall development", this notion that work should proceed in discrete stages, from analysis via design to implementation and then testing. The whirlpool model maintains that later stages (like implementation and testing) affect earlier stages (like analysis and design). And boy, is that ever true!

In fact, this has sunk so deep into our mental model of the project, that we don't really trust a synopsis until it's been implemented. The synopses are the rough consensus that we've all agreed upon so far, but until there's running code too, the synopsis is assumed to come with a big grain of NaCl.


The terminology that seems to emerge for this is that a synopsis becomes increasingly frozen over time, but before it reaches that point through actual empirical implementing, it's slushy or even liquid. Today, we have a few frozen bits of spec, lots of slushy bits, and a few liquid bits. Slushy is good; it means that we have some backing from implementations, but the spec and the implementations don't quite agree yet. I like that part, and since I'm an early adopter by temperament, I'm fully prepared to work under such conditions.

Concrete example: Larry made some changes to multi semantics; Jonathan got visibly worried, but couldn't quite put his finger on why. Recently he put his worries into words, which unsurprisingly were backed up by implementation concerns. Larry obliged and refined the semantics to address those concerns. The implementations drive the specification.

That last example is also a suitable instance of another metaphor: various parts of the spec seem to undergo some kind of stochastic hill-climbing in a hypothetical space. Along the way, it might reach several local maxima, in which some of the concerns have been addressed, but there is still gnashing of teeth over others. Usually, when we reach a global maximum, everybody just knows: this is it. (Well, at least to the extent that hill-climbing guarantees that the maximum really is global.)

All this is emphasized in the Perl 6 motto "Second System Syndrome Done Right". Redesigning things on the basis of empirical feedback. And it's pretty good.


There are also a couple of pieces of spec where I think we haven't found the global maximum yet, or even a local one. That's what I really set out to write about today. I feel a bit like MJD now; what you read so far was only an introduction of sorts.

Let's split things into two parts: slight unease and abstraction astronautism. The former are parts where I believe we're on the right track but not quite there yet. The latter are parts that I believe were too ambitiously designed from the beginning, and that are probably better thrown out wholesale. The former requires out-of-the-box thinking; the latter would need something more like out-of-the-box courage.

Slight unease

Abstraction astronautism

A third category would be "areas where I wish there were more spec, period". But searching for those is the objective of being all over the place with Rakudo, writing different application code, trying new and exciting things. Such discussion takes place all the time on IRC, over pieces of code, or on the p6l list. So I don't have a pent-up need to blog about those.