Just A Summary

A couple of articles back, I reviewed Smalltalk Best Practice Patterns and mentioned that it’s a book that concentrates on the tactics of programming rather than the big strategic stuff. Beck even takes his life in his hands and lays down a set of patterns for laying out code. The (very short) set of patterns he comes up with do seem to generate remarkably clear code.

I’m a big fan of this book, and I’ve lifted many of the ideas about how to structure Smalltalk code and used them when I’m writing OO Perl (to the extent that I sometimes find myself wishing that Perl had Smalltalk like message selectors), so now I’m toying with the idea of using Beck’s rules, or something like them, for laying out my Perl code.

As most of you probably know, unless you’re one of the people who came here via a link from java.net, I write a summary every week of the ongoing developments on the Perl 6 development mailing lists. Which means, if nothing else, that my review of Perl 6 Essentials by Randal, Sugalski & Tötsch might be just a little partial.

One of the less satisfying sessions/panels at OSCON this year was the ‘Perl Certification’ Panel, in which a panel of various luminaries, moderated by Tim Maher of the Seattle Perl Users’ Group spoke inconclusively about whether there was a need for Perl Certification. It seems to me that, if you’re going to have a panel on this kind of topic, you must make sure that your moderator is impartial (but not disinterested). Tim Maher, for all his many virtues, was not impartial.

I arrived late to the panel, so I could be forming a bad impression, but it seemed to me the panel had the cart before the horse, and any similar panel will also have such an ungainly configuration, and here’s why:

Picture this: A magician sits in front of you with a pack of cards in his hands. He turns over the top card, it’s the Two of Hearts. He has you sign it. He then turns the card back over then takes the top card from the deck and pushes it home somewhere in the middle. He asks you to snap your fingers, then he turns over the top card of the deck again. It’s your signed Two of Hearts.

What I’ve described is the opening of one of the classics of card magic, called The Ambitious Card, in which a signed, selected card repeatedly jumps to the top of the deck in ever more implausible conditions. On the face of it, the effect is simple, the card just keeps jumping to the top of the deck. Behind the scenes, the method is simple too; you just have to execute a hidden move so that it looks like you’re really doing what you claim to be doing. And there’s the rub. Though I say so myself, I can execute the required move with no little skill, but if I stop to think of the complexities of what I’m doing, I won’t be able to do it well. I certainly can’t explain how it’s done to another magician, well, I can, but the explanation goes along the lines of “Just practice ‘til it looks like the real thing”.

What does this have to do with complexity management? Well, apart from the fact that a good magic trick should be presented in such a way that, no matter how complex the method, the audience just sees the magic, obviously. But there I go again, using the tool we all instinctively use to manage complexity. That tool is the word ‘just’. We all do it, we push the complexities of something behind what I’ve taken to calling a ‘Just Story’. Here’s a just story for sole meunière:

The fish, fried in butter, is transferred to a serving dish and over it is poured a quantity of freshly cooked, hissing, foaming butter. A squeeze of lemon juice, a scrap of parsley, and the dish is ready.

Couldn’t be simpler, could it? Well… Elizabeth David, in French Provincial Cookery goes on to explain the full complexity of the dish so:

The Quality Without A Name is a phrase coined by Christopher Alexander in The Timeless Way of Building to describe the feeling of satisfaction and contentment engendered by good building. He later went on to call it ‘life’, but a friend of mine described it as ‘The Tao of Building’, which seems rather appropriate too. The Timeless Way of Building is a fantastic, if somewhat overwritten book, introducing Alexander’s themes and ideas about how modern architects and builders can recapture the qualities inherent in great (usually old) buildings.

Alexander later went on to crystallize his ideas about how to lay out cities, towns, neighbourhoods, houses, rooms, windows, etc in his massively influential book, A Pattern Language, in which Alexander and his co-authors attempted to set down a ‘language’ that would enable anyone to design and build somewhere that possessed the Quality Without a Name for themselves. Sadly, as they admit later, they failed in this attempt; efforts to use this pattern language by laymen resulted in interesting, but flawed buildings. Despite the failure (in Alexander’s terms) it’s a great book; the prose can be a little annoying at times, but the analysis is deep, and mind-changing. Here’s an extract from one of the patterns:

208. Gradual Stiffening

Somewhat to my own surprise, I’m at YAPC::Europe in Paris. I pitched up to the early birds session and offered a talk if they’d had any people pull out and it turned out that they had—Ronan Oger was due to give a half day tutorial on SVG-based GUIs on the first afternoon of the conference, but he wasn’t going to make it in time, so the organizers swapped his talk with Dave Cross’s talk on Tieing and Overloading Objects in Perl.

Dave’s talk is an hour shorter than Ronan’s, so Simon Wistow, Richard Clamp and me offered three 20 minute talks to fill the gaps.

There was a catch; all the talks I’d taken to America had been aimed at 40 minutes and for the life of me I couldn’t see how to make them any shorter.

“Never mind,” I thought, “I can waffle about Pixie or refactoring or something, or if all else fails I can brush off 12 Step Perl and get my audience to do at least half of the work for me.

This was my plan, but then I had this idea for a cunning trick to make Perl’s method inheritance system a little more sane.

Bah! The only trouble with being in full control of a website is that you’ve got nobody to blame when you screw up.

I was talking to Gavin Estey on iChat about the problems inherent in interviewing a new programmer. The cost of screwing up can be enormous. How do you find out whether the candidate is for real? How do you do it quickly?

Well, those are sticky questions, and there’s a discussion of Perl certification and standards coming up once I’ve marshalled my thoughts properly.

Anyway, Gavin showed me one of the quiz questions they used in his organization:

What’s wrong with the following code?

open FILE, "<$filename";
print FILE '$parameter1, ';
print FILE '$parameter2, ';
print FILE '$parameter3\n';
close FILE;

A good time was had by all

This was my first OSCON, I’ve usually been unable to make it over, due either to lack of time, finances, or both. This time there was a lack of finances and plenty of time, so we threw caution to the wind and headed off to sunny Portland.

And boy, was it sunny—I thought the Pacific Northwest was supposed to be rainy.

PONIE announced

The conference proper opened with Larry’s State of the Onion speech where he announced Fotango’s sponsorship of PONIE, Arthur Bergman’s attempt to port Perl 5’s underlying data structures to Parrot. The idea is that, if everything goes well, we’ll be able to keep Perl 5’s front end (parser, opcode generation, etc), but use Parrot as the back end. Approaching things in this fashion should mean that the existing CPAN codebase of XS based modules will simply need a recompilation to run on Ponie, which is fantastic.

James Duncan of Fotango points out that sponsoring Arthur to do this work is naked self interest on Fotango’s part; they have nearly 100,000 lines of Perl 5 code which depend to a greater or lesser extent on CPAN modules, the most obvious of which is the DBI family of modules, which provide standardized Perl access SQL databases. By porting Perl 5 to Parrot, Fotango will be able to jump to the new, JIT-enabled engine and then slowly port their Perl 5 codebase to Perl 6 as that language becomes available.

The beauty of Ponie is that, whether the port proves to be a success or not, Perl wins anyway because, in order to know if Ponie works properly, the team are going to have to write a comprehensive test and possibly documentation suite for Perl’s internals, and those tests will be available in Perl 5, and better test coverage is always a good thing.

And Perl 6 wins too, if Ponie succeeds, we get the Perl 5 emulation for free, and the development of such a non-trivial Parrot application should really help shake out the bugs bottlenecks in Parrot, which should help Dan with the Pie-thon challenge if nothing else.

Perl 6 Rules! (or do I mean Perl6::Rules?)

Ever since Apocalypse 5 outlined Perl 6 Rules and Grammars – Larry’s reinvention/replacement of regular expressions, there’s been a good deal of anticipation and muttering. Everyone seems to want them, but the mutterers have doubted whether it will be possible to implement them.

They should doubt no more.

In his last talk of the conference, Damian presented an overview of Perl 6’s rules system. With running code. Okay, it’s not complete, it’s not ready for public consumption, and Damian’s just disappeared off for a well deserved month long holiday. But it will be ready for Christmas. Bets on which Christmas are not being accepted.

There are several amazing things about the module that Damian presented:

1. It’s in pure perl
2. It’s 700 lines long
3. It comes with a comprehensive set of debugging methods
4. It was entirely written over the course of OSCON (that’s if we don’t count the months of Damian’s ‘mind time’ it’s taken up while he planned it out…)

It’s not (by any stretch of the imagination) complete, but it’s a fantastic piece of work, I’m eager (nay panting) to see the completed module.

Once the module is released there’s still a good deal of work to be done, but this is a vital step in the process of bootstrapping Perl 6 (in his later Apocalypses Larry has taken to using Perl 6 rules to describe Perl 6 syntax), both the language proper, but also the possibility of more, better, and complementary Perl6::* modules implementing chunks of Perl 6 functionality in Perl 5 where people can experiment with the language before it exists for good.

I have a cunning Plot

On the Thursday of OSCON, inspired by Leon Brocard’s “Little Languages in Parrot” talk and Dan’s “What’s new in Parrot” talk, I attempted to implement a tiny Scheme interpreter on Parrot in one day (we called it PLOT – Parrot gets Lisp on OSCON Thursday, which is a lousy acronym but we were pressed for time). And failed dismally. But we do have the empty list implemented as a closure, so it’s a simple matter of programming from here on…

And there’s more

Of course, that’s not everything, but it’s certainly the highlights from the Perl 6 point of view. I shall probably write about some of the other sessions later.