Just A Summary : Category review, everything about review

Reading Beautiful Code

pdcawley@bofh.org.uk (Piers Cawley) — Tue, 21 Aug 2007 18:49:57 -0500

I’m reading Beautiful Code and it’s very good indeed. However, you have to feel sorry for Tim Bray – his chapter, “Finding Things” is excellent, as you’d expect. The only problem is, he’s following Jon Bentley, author of that perennial classic, Programming Pearls. It’s been a while since I (re)read anything by Bentley and I’d forgotten how good his prose was.

Which isn’t to say that Tim Bray is a bad writer. Far from it. It’s just that Jon Bentley is a very good one indeed.

Apart from that, Beautiful Code is a cracking book so far, and the royalties go to Amnesty International. You should buy a copy.

Holiday Reading

pdcawley@bofh.org.uk (Piers Cawley) — Sat, 21 Jul 2007 17:21:00 -0500

Mmm… back from Scotland with a chunk of reading done:

Harry Potter And The Deathly Hallows. Mmm… top notch stuff. Wraps up the series perfectly.

The Book Thief. Wow! Seriously… wow. Whatever you do, don’t read the last chapter of this in public. I was a wreck. Beautiful. Sad. Really Sad. Life affirming stuff. Read it.

The Complete Polysyllabic Spree. Nick Hornby writes exceedingly good litcrit/columns.

Compilers: Principles, Techniques and Tools aka The Dragon Book. Good, crunchy computer science full of stuff I’ve skirted around learning for ages now. I’m still far from finished with this book. It does feel old fashioned though, and a little light on techniques for implementing highly dynamic languages.

Programming Language Pragmatics. More seriously crunchy computer science; I’ve only really skimmed the surface of this one so far, but I’m liking it a lot so far.

The Amazing Adventures of Kavalier & Clay. Another wow. What’s not to like? Golden Age Comic book history. Close up magic and escape artistry. Nazis! Citizen Kane! Astonishing, page turning, storytelling. No wonder it won a Pulitzer. It might well make you cry too (though not as much as The Book Thief)

The Essential Turing. You know how everyone who knows anything about computing tells you that Alan Turing was a genius? They’re right. I knew they were right before I read On Computable Numbers, with an Application to the Entscheidungsproblem (the first paper in this book and the only one I’ve read so far), but the paper drove home how much of a genius he was. The way he bootstraps from the idea of the Turing Machine to a Universal Turing Machine is just beautiful – one minute he’s describing the basic workings of a seemingly simple machine and a few conventions he intends to use and then within a few pages he’s implementing a Universal Turing Machine and describing it using the kind Higher Order Functions that get ‘metaprogrammers’ so excited whenever the come across a language like Ruby. Great, great stuff.

Why don't more books work like this?

pdcawley@bofh.org.uk (Piers Cawley) — Sun, 06 May 2007 02:57:00 -0500

When you read Christopher Alexander’s A Pattern Language, the patterns within the language are interdependent and ordered from big patterns down to small ones. Each pattern has a number and wherever one pattern refers to another it’s referenced with both the pattern’s name and its number.

Beck, Fowler and the Gang of Four (if memory serves) go one better, wherever they reference a pattern, they give the pattern’s page number (ah, the joys of computer typesetting). I’m not sure it’s an enormous improvement over pattern numbers with the pattern numbers in the running heads, but both practices make the books easy to use.

Writing this up as mini patterns, (very roughly based on Alexander’s pattern format) you’d have something like:

A Tiny Pattern Language for technical writers

1. Organizing Principle

You’re writing a Pattern Language on paper

Without some organizing principle, a random collection of patterns is just that

When you’re organizing material in a book which needs to be usable both as a learning resource and as reference material there’s a tension between the needs of the new reader who wants each pattern to follow logically from the patterns she has already read about, and the needs of a seasoned pattern user who needs to find details of a specific pattern.

It’s tempting to take the view that a reader is only new once, so it’s best to arrange the material to suit the reference user and put your patterns in alphabetical order. Don’t. If your material doesn’t make sense to the new reader, they’ll never reach the point where they use your book as a reference.

Therefore:

Arrange your patterns for new readers. Provide an index and cross references to support reference use

Use Arrange Patterns by Scale(2) to order your patterns and Reference by Name and Number(3) for your cross references. Provide a Table of Contents and an Alphabetical Index.

2. Arrange Patterns by Scale

You’re choosing an Organizing Principle(1) for your pattern language

It’s hard to understand a pattern without some idea of where it fits in the scheme of things

Read A Pattern Language, look at the way that each pattern in the book flows from the ones that precede it and leads you on to the patterns that support it. There’s a huge amount of information in that book, but it just flows. It has The Quality Without A Name.

Now read Universal Principles of Design, another book which contains a great deal of good information backed up with great pictures and some real research. Each spread in the book is analogous to a Design Pattern, and each spread is great. It’s a bugger to read though. The designers have chosen to arrange their principles in alphabetical order; reading through is like being taken on a drunkard’s walk by a conceptual grasshopper. Many of the principles are hierarchical, but the reader is left to work that out for themselves. It reminds me of the joke about reading a dictionary; the content’s great, but the characterisation and plot are all over the place.

Therefore:

Find patterns that use other patterns, put them before the patterns they use. Group patterns with a similar scale or motivation in chapters.

3. Reference by name and page number

You’re referring to a pattern.

Why can’t books be more like the web?

We’ve all done it I’m sure; one part of a book refers to another part and gives just the section title. We curse the author or his editor and go scurrying off to the table of contents or the index to find the referenced page and then turn to it, all the while keeping our index finger jammed between the pages so we don’t lose our original place.

Or the author has taken pity on us and, following the Chicago manual of style, supplies a section number (with multiple decimal points) and we start flipping forwards or backwards to find the right section number. This is less fun than it could be because no two sections are the same length. Or the content’s arranged alphabetically, and every section is the same length, but we’re not entirely sure of how many sections start with any given letter – I’m looking at you Universal Principles of Design.

There has to be a better way. Wouldn’t it be great if we could just go directly to the right page as if we were following a hypertext link?

Indeed it would.

Therefore:

Whenever you refer to another pattern, use both the pattern’s name and its page number; that way the reader can turn directly to the right page without having to visit an index or flip hopefully trying to guess how long each section is.

What next?

Obviously we need to hunt down and deliver a good telling off to authors, editors and publishing houses that don’t follow this pattern language.

Would you believe that I started this article meaning to write a review of Universal Principles of Design? Despite my grumbles about it above, it’s a cracking book full of really meaty stuff. I commend it to you all.

Spiers and Boden: Songs

pdcawley@bofh.org.uk (Piers Cawley) — Sat, 15 Oct 2005 09:22:00 -0500

Listen to this. You’ll not regret it.

Whee! John Spiers and Jon Boden have finally made an album (Songs) that sounds as good as they do live. Not that Through and Through and Bellow are bad albums, it’s just that their playing has improved somewhat since they were recorded. On stage, Jon and John play with an almost telepathic level of communication. Songs captures that magic.

Songs is the companion piece to Tunes[1] and it fairly fizzes with excitement. The material is almost all Big Ballads, and these are handled with a freshness and authority that is great to hear. The only ballad here that’s familiar to me from other singers is Lucy Wan, which Martin Carthy does so well. Jon and John give the nod to that version as their inspiration, but the result is entirely their own.

There’s one modern piece, Innocent When You Dream by Tom Waits, and it’s fabulous—the sort of song that wouldn’t sound out of place in Peter Bellamy’s repertoire next to the obscure Dylan covers, big ballads and the Kipling. You can hear Bellamy’s influence everywhere. He’s the source for one song (Derry Gaol), but Jon’s singing style has Bellamy written all over it. Like Bellamy, Jon will start a song with a testing range at least three notes higher than seems sensible and then thrill you as he hits all the high note with ease³. And, just like Bellamy, Jon sounds like nobody else⁴.

Buy this CD. And if you get a chance, go and see them live. Good as this album is, these guys are still improving and in a year or so this is going to sound a little bit disappointing compared to what they’re doing on stage. If they can keep doing that trick, who knows what’s going to happen.

¹ Although Tunes was released earlier this year, I’ve not actually listened to it; I’m more of a songs person I guess.

² A year or so ago I found myself singing a high harmony while Jon sang Bellamy’s setting of The Old Songs at the Cumberland singing session ~~- I was up next and that was the song I was planning to sing so when Jon started in on it I thought “What the hell?” and came in with a harmony line -~~ I didn’t know I could go so high. Those notes are often there if you’ve got the nerve to really go for them; they only disappear if you don’t think you can get them.

³ There’s nothing here like Bellamy’s astonishing Santa Fe Trail where, having sung the whole thing at very high altitude he repeats the last chorus singing a high harmony line that leaves you gasping. But some of the stuff he was singing with Bellowhead a few weeks ago was definitely getting that way.

⁴ It’s the old problem isn’t it? Bellamy sounded entirely like himself; the best way to follow his lead is to sound entirely like yourself.

Had we but world enough, and time: Serenity

pdcawley@bofh.org.uk (Piers Cawley) — Fri, 07 Oct 2005 00:51:00 -0500

Joss Whedon’s Firefly was a sf series that was never given time; episodes were jumbled by the network and the show got cancelled just when it was starting to build a serious fanbase. And that’s all she wrote.

Except, as fans of Buffy and Angel know, Joss Whedon doesn’t tell the same stories as everyone else. He managed to hold his cast together and found the funding to make Serenity. It isn’t quite the film of series they didn’t have time to make, but it comes close.

Capsule review: I liked it. I liked it a lot. You should see it.

For a slightly longer, and possibly spoilery review, kindly step behind this curtain…

I really liked Firefly. I pulled the episodes down via bittorrent as they became available and watched them in all their lo-fi glory, putting up with jaggies, out of sync audio and the rest. I bought the DVDs, downloaded the soundtrack and, a couple of weeks ago, went to one of UK’s “Can’t Stop The Signal” previews of the finished movie and laughed in all the right places as, instead of the usual previews, Joss introduced the film.

The film is great. Like most modern sf films, it’s something of a ride. There’s even the cliche of the big fight over the bottomless pit in there somewhere. But there’s snappy dialogue and food for thought too, and some beautifully violent fights (everyone else take note, casting a dancer as your lethal weapon is a good move).

However…

But at my back I always hear
Time’s wingèd chariot hurrying near

—Andrew Marvell, To His Coy Mistress

You can almost hear Time’s chariot as you watch Serenity. The shows were never slow, but the film rattles along at astonishing speed: there’s no time for sitting round the galley table; no time to give sense of lives being lived; no time for Shepherd Book; no time for anything that isn’t going to be relevant within the space of this film. Most films do this, but it’s more noticeable when you already know the characters from a TV series.

The decision makers at Fox took that time away. The bastards. I really want to see Serenity get spun off into another TV series, but the grapevine has it that that’s not going to happen—apparently Fox won’t relinquish the rights. The bastards.

“If you can’t do something smart, do something right”

Thomas More: The last temptation is the final treason,
To do the right thing for the wrong reason

—TS Eliot Murder in the Cathedral

If the film has a message, and I think it does, it’s the same one that Whedon sent in Buffy and Angel. Morality is about personal choice. When it comes down to it, integrity is all that we have and that integrity only exists if you have the freedom to do the wrong thing. For Joss, the greatest sin is taking someone’s freedom to sin from them, because by doing that you take away their chance of redemption.

Which brings us perilously close to politics, but I’ll save that for another entry.

A bright light on the culinary road to Damascus

pdcawley@bofh.org.uk (Piers Cawley) — Wed, 03 Aug 2005 17:17:26 -0500

If you’ve eaten with me, you might be aware that I’m not a big one for chili heat. I don’t mind it, but you won’t find me chopping up the Scotch Bonnets for a mole or ladling out the chili oil in a Chinese restaurant.

If you’d suggested that I would cook something that involved 3 tablespoons full of chili oil, complete with the sludge of seeds from the bottom of the jar, in a dish for two people I would have thought you had gone mad. If you had then suggested that I’d love the resulting dish with a passion that made me want to rush off and blog about it…

It all started 4 years ago when I read an article in The Observer by Fuchsia Dunlop about her time in Sichuan Province and how she became the first Western woman to study at the Chengdu School of Cookery, and how she ended up writing a book about Sichuan Cookery. It was a fabulous article, beautifully written and it set my mouth watering as I read it. “I should get that book when it comes out” I thought, and promptly forgot about it.

A few weeks ago, browsing in the Newcastle branch of Borders, I came across the paperback edition and grabbed it, took it home and read it in short order. Wow. So many Western books about Chinese food (and probably other foreign foods, I only really “know” about Chinese food) are full of compromises, on ingredients, recipe choice, cooking methods… I don’t want to learn how to make westernised restaurant standards like day glo sweet and sour pork, or chop suey. I want to know how to make Siu Yuk, or the fabulous ‘Braised Belly Pork with Sweet Preserved Vegetables’ they do at Mangos, or the amazing ‘fried blood’ I once ate with Jon Singer¹ at a hole in the wall Chinese Restaurant in Washington DC’s Chinatown.

Sichuan Food definitely goes in the ‘authentic’ section of your cookery bookshelf. Heck, it took me about a month to get the store cupboard stocked with basic ingredients and I’m still trying to find a source for dried sky facing chilies and Sichuan pickled chilies, but tonight I finally cooked something from it. I went for ‘Cold Chicken Slices in a Hot and Numbing Sauce’. The thing was simplicity itself: Boil the chicken (at least free range, in our case organic), for half an hour, cover it in cold water for a couple of hours to cool down, slice the meat from one side, stick it in a bowl with some sliced spring onions, sprinkle a teaspoon of ground roast sichuan pepper over it, pour on a sauce made from the aforementioned 3 tablespoons of (home made) chili oil + sludge, sweetened soy sauce and a splash of sesame oil, mix it up and serve with rice.

It was fabulous. I confess that I was prepared to find it inedibly hot, but wow. The combination of flavours and the amazing tingly ‘numbing’ sensation from the sichuan pepper took away the burn and let you savour the tastes and textures. I’d probably eat an old boot if you chopped it up small and covered it with this sauce. But on top quality chicken… I know what I’m doing next time we have leftovers from a roast bird.

I dunno what I’m doing next from this book, but I’m delighted to report that on first showing it’s at least as good to cook from as it is to read. Definitely one for the shelf in the kitchen with Nigel, Hugh, Elizabeth and Fergus. I just wish I’d had the sense to remember to buy it in hardback.

¹ If you ever meet Jon, for heaven’s sake don’t play the “I’ve eaten weirder Chinese food than you” game. I actually managed to outweird him on the Japanese stakes, but I reckon we probably managed a Chinese tie by having the fried blood…

The Pickaxe Book

pdcawley@bofh.org.uk (Piers Cawley) — Mon, 01 Aug 2005 14:20:00 -0500

I can’t remember when Adam Turoff pointed me at Ruby On Rails, but I’m still grateful. Blame Adam for the fact that this weblog is no longer running on Movable Type, but on Typo. My initial plan was to roll my own blogging software on top of Rails, but by the time I got my act together it just made sense to grab an existing package and extend it as required.

I first heard about Ruby when I read Andy Hunt and Dave Thomas’s excellent book The Pragmatic Programmer. I thought, “that looks interesting”, so I read the first edition of Programming Ruby aka the Pickaxe Book, learned the syntax and some of the idioms and then sort of forget about it. As a programming language Ruby pushes a lot of my buttons: it has closures, objects all the way down, dynamic typing and its refreshingly concise. However, I never quite got round to writing anything in it (not the language’s fault, I wasn’t writing anything in anything at the time).

Then along came Ruby on Rails and it’s lovely. I saw the first version of the Rails Video and it knocked me out. Rails does so much right. Here was a web development tool that did most of the heavy lifting for you, and makes it easy to do things Right. David Heinemeier Hansson was obviously getting a great deal of leverage from Ruby’s dynamic nature and I wanted some of that.

However, I found that Ruby had moved on since I skimmed the first Pickaxe so I got hold of a copy of the second edition of Programming Ruby. What a cracking book it is. My personal benchmark of quality when it comes to a language reference is the first edition of Programming Perl which, as well as being a language reference was an introduction to a programming ethos. Whilst I don’t think the Pickaxe is quite that good, it’s definitely up there. The chapter on ‘Duck Typing’, for instance, is wonderful. It’s a well made argument for dynamic typing and it deserves to be widely read. I sometimes think that there are two sorts of programmers in the world, those who think typed values are essential, and those who think typed variables are essential. I’m definitely a typed values kind of guy. Typed variables have their place, but that place is in the optimization toolbox next to the profiler.

Ruby’s a great language. I don’t think it’ll ever be my primary language—I still have high hopes for Perl 6, which will have all the things I like about Ruby whilst addressing some of the things about it that make me uncomfortable. But in the unlikely event that Perl 6 crashes and burns, Perl 5 finally has a competitor that I enjoy using if only because I’m sick of typing:

sub foo {
  my $self = shift;
  my($arg1, $arg2) = @_;

at the start of every method.

def foo(arg1, arg2)

is just so much shorter. And until I can do

method foo($arg1, $arg2) {

Ruby will entice me. Maybe I should just get Emacs to fill in the Perl 5 boiler plate…

Quite Ugly One Morning

pdcawley@bofh.org.uk (Piers Cawley) — Fri, 03 Sep 2004 03:39:00 -0500

Spurred on by the forthcoming adaptation on ITV, I’ve finally got round to reading Christopher Brookmyre’s first novel, Quite Ugly One Morning

Wow.

If you can make it past the (quite disgusting) first chapter, then you’ll be in it for the long haul. Great characters, spiky dialogue, twisty plot, worrying prescience and some fabulously gruesome set pieces and comeuppances.

So, in summary. Buy this book. Then do what I did and buy the other Parlabane books too; they’re worth it for the titles alone.

'Extreme Building'

pdcawley@bofh.org.uk (Piers Cawley) — Sat, 30 Aug 2003 09:54:00 -0500

Our experience as contractors, engineers and architects during the last 15 years has proved one thing over and over again: The things placed on drawings are inevitably – always – wrong in many particulars. Drawings serve as an important rough sketch of something that will be built, but must be executed with constant attention to room shape, light, wall and ceiling detail, openings – above all to the feelings which arise in each place, in the construction, as it is taking shape. These feelings are too complicated to predict and cannot be predicted. When a building is built from plans that are conceived on the drawing board and then simply built, the result is sterile at best – silly most of the time – and sometimes unthinkably bad. This is something familiar in virtually all large buildings that have been built since 1950. It is inevitable, given the process of construction used to build them. And it is inevitable that this process must lead to unsatisfactory results.

—Christopher Alexander, Gary Black & Miyoko Tsutsui The Mary Rose Museum

Another installment in my ongoing series of reviews of books that Amazon will take an age to deliver.

The Mary Rose Museum is an account of the Center for Environmental Structure’s bid to build a museum around the Mary Rose, Henry VIII’s flagship, which, in 1545 unaccountably sank in calm seas, in the sight of the King himself¹ with the loss of nearly 700 men. The story of how the wreck was found, raised and conserved is pretty impressive in itself. I can remember watching BBC specials on the process as it was happening and being amazed at the dedication/insanity of those involved, but that’s not really what Alexander’s book is about.

In 1991, Christopher Alexander was in conversation with Prince Charles (whose interest in architecture is (in)famous). They were lamenting the then design for a museum to be built over where the Mary Rose still lies beneath a huge tent, continuously sprayed with a cold mist of water to prevent any decay of the timbers. The proposed design was for yet another anonymous hangar-like structure at odds with the other buildings in the Portsmouth Naval Dockyard, and not exactly sympathetic to either the Mary Rose or HMS Victory which sits in a nearby dry dock. The Prince sketched (probably not on a fag packet, but who knows) a profile, saying to Alexander “What about something like this?”, and off Alexander went.

At Charles’ request, the Mary Rose Trust commissioned Alexander to produce the proposal for building The Mary Rose Museum that is, ostensibly what this book is about. The bulk of the book’s 128 pages is taken up by a description of the proposed museum, outlining its development from the original rough sketch through to a fully costed, structurally feasible design.

At this point, the principle sponsor backed out leaving the project with no funds and it had to be shelved. Alexander says that, by then, he and his team had put in some 5000 man hours of work on the project; I’m sure they must have been gutted to have the plug pulled. A smaller section at the back then goes on to discuss the (much rougher) work the team did on redesigning the museum so that it could be built in incremental fashion without needing all the funds up front in the hope that the Trust’s funding could be spent on something permanent rather than having to spend a large amount of the donated money on temporary measures to maintain the structural integrity of the current ‘tent’ over the ship.

So, it’s a war story from a failed project, why should you part with the thick end of Â£30 to read about that? And what does all this have to do with programming? Here’s why: Christopher Alexander is the most influential bricks and mortar architect that the world of computer programming has ever known, if only for his work on Pattern Languages and ‘The Quality Without a Name’. As a literary form, the design pattern and the larger pattern language are fabulously useful (and egregiously abused) ways of describing how to solve many of the problems we face as programmers.

However, what is often overlooked about Alexander’s work is that an awful lot of what he advocates about the process of generating a room, building or town foreshadows the processes advocated by the Extreme Programming people. You should not be surprised to learn that Kent Beck, author of the seminal book on XP, was also one of the earliest writers to use design patterns as a way of addressing programming issues.

In The Mary Rose Museum, Alexander describes the ‘agile’ process his team uses on projects, and he also shows the basic contracts between Owner and Architect, and Architect and Subcontractor that he and his team use when building.

As a houseowner who had some fairly substantial house renovation done I’ve been a signatory to a standard RIBA contract for building works, and it’s a very different beast indeed from the Center for Environmental Structure (CES) contracts. I would rather have signed the CES ones. Alexander maintains, and I think I agree with him, that his form of contract deliberately nurtures the process of building something that will live, while the standard contracts are based on the myth that the plan is how it will be and any variation will cost the client. The CES contracts state up front that change happens, and handle that change without having tons of ‘extras’ added to the cost. Here’s an extract from the Craftsman/Subcontractor[2] contract.

ARTICLE 5. CRAFTSMAN’S GOAL. The ultimate purpose of this agreement is to secure the craftsman’s work under conditions which make the craftsman’s work a work of beauty and pride and self-respect, and in which the craftsman leaves behind work he is proud of, and can cherish in the future.

It is specifically understood that the craftsman’s goal is not only to be paid for his work, but that the beauty and satisfaction of the work itself provide part of the craftsman’s reward. To this end, the craftsman shall be treated as an artist who has some power and control over his work as necessary to allow the creation of a beautiful and fitting work within limits accepted by CES.

It seems to me, as someone who believes that we programmers are more craftsmen than engineers, that the CES contracts for building works may well offer a useful model for designing contracts for building software using agile processes. Certainly Alexander has interesting things to say that will repay your careful reading and consideration.

¹ One theory my wife has heard is that someone on board said “Ee look, there’s t’ King!” at which point everyone on board rushed over to one side of the ship to take a look, and the subsequent heeling of the ship meant she started shipping water through the lowest gun ports.

² The contract is careful always to refer to subcontractors as craftsmen “in order to emphasize the craft-like nature of the work which CES expects.”

"The best thing for being sad"

pdcawley@bofh.org.uk (Piers Cawley) — Fri, 29 Aug 2003 06:28:00 -0500

“The best thing for being sad,” replied Merlin, beginning to puff and blow, “is to learn something. That’s the only thing that never fails. You may grow old and trembling in your anatomies, you may lie awake at night listening to the disorder of your veins, you may miss your only love, you may see the world about you devastated by evil lunatics, or know your honour trampled in the sewers of baser minds. There is only one thing for it then—to learn. Learn why the world wags and what wags it. That is the only thing which the mind can never exhaust, never alienate, never be tortured by, never fear or distrust, and never dream of regretting. Learning is the only thing for you. Look what a lot of things there are to learn.” —T.H. White, The Once and Future King

T.H. White is one of my favourite writers. It’s easy to be dismissive of The Once and Future King, based on the Disney adaptation—which, like their version of The Jungle Books, is great fun but a travesty of the original. However, as I hope the extract shows, there’s rather more to him than that.

My favourite chapter in the book was the one dealing with the night Wart spent in the castle mews with the falcons and the baleful nightmare, Cully. Ever since I read it I’ve been fascinated by falconry—I’ll know I’ve made my fortune when I can retire to a large house in the country and keep and become a falconer. I mentioned this to Gill shortly after we met and she pressed The Goshawk on me. Wow. This is a fabulously written account of White’s attempts to train a Goshawk using a medieval textbook as his guide (even when he wrote the book, the profession had moved on a great deal, but White didn’t know that). It’s been described by austringers¹ as the ideal ‘how not to’ book. But you don’t read it for the techniques, you read it for White’s perfect prose, for the boundless patience of the man and the seemingly boundless stubbornness of the bloodyminded Cully. I’ve flown a Harris Hawk on a course that Gill arranged for my birthday one year, walking around with a hawk on your fist, calmly talking to it and getting it used to you is (for me) an indescribable experience; the best I can do is point at The Goshawk and say “Read that!”

I wish I could say that Merlin’s speech branded itself on my brain when I first read it around 25 years ago, but sadly, I can’t. It only had that effect when I logged into my Linux box one morning and my standard .profile ran fortune and up it popped. Merlin’s dead right you know, the process of learning things is the finest pill to purge melancholy I know. At my father-in-law’s funeral (he had been a stalwart of the WEA for a large part of his life), we took that passage and had it printed up on cards for the mourners, and Gill used it as a reading. Everyone who knew him remarked on how appropriate and cheering it was. I hope that it will be just as appropriate a reading for me when my time comes.

¹ Fabulous word isn’t it? An austringer is someone who flies hawks, as opposed to a falconer, who flies falcons.

Laying out code

pdcawley@bofh.org.uk (Piers Cawley) — Sat, 16 Aug 2003 13:51:00 -0500

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.

Here’s a method from Pixie::Proxy (one of the scarier classes in Pixie I must admit):


sub _px_extraction_thaw {
  my $self = shift;
  my $pixie = Pixie->get_the_current_pixie;
  my $ret = $pixie->cache_get($self->_oid);

  if ( defined $ret ) { $pixie->obliterate($self); return $ret; }

  $self->px_lock_strategy( $pixie->get_the_current_lock_strategy );

  if ($self->px_class->px_is_immediate) {
   my $oid = $self->_oid;
   $pixie->obliterate($self);
   return $pixie->_get($oid);
 }
  else {
   $self->px_the_store($pixie);
   $pixie->cache_insert($self);
   return $self;
 }
}

Now, here it is again reformatted according to my adaptation of Beck’s rules.


sub _px_extraction_thaw {
  my $self = shift;
  my $pixie = Pixie->get_the_current_pixie;
  my $ret = $pixie->cache_get($self->_oid);

  if ( defined $ret ) { $pixie->obliterate($self); return $ret; }

  $self->px_lock_strategy( $pixie->get_the_current_lock_strategy );

  if ($self->px_class->px_is_immediate)
    { my $oid = $self->_oid;
     $pixie->obliterate($self);
     return $pixie->_get($oid) }
  else
    { $self->px_the_store($pixie);
     $pixie->cache_insert($self);
     return $self; }
}

The main change in appearance comes from using what Beck calls rectangular blocks. Moving to this style has shortened the method by three lines, which isn’t bad. Moving to using cuddled elses¹ would only have saved one line and I don’t like them anyway because I tend to lose the else. With rectangular blocks, the control structure is still evident, which is nice.

It’s quite strange looking at that code; it looks odd, but I don’t think it looks actively bad. I’m off to recast a whole module in this style and see if I can boil things down to as compact a set of rules as Beck came up with. Or I might decide it looks horrible, but I do think it’s worth a look.

Has anyone else tried anything like this? Did it work for you?

¹ A cuddled else looks like } else { and is evil, bad and wrong.

Essential Perl 6

pdcawley@bofh.org.uk (Piers Cawley) — Fri, 15 Aug 2003 10:13:00 -0500

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.

Any book which aims to hit a target as mobile as Perl 6 and Parrot¹ is always going to have a hard time, but the writers are all intimately involved in their design and development, so they’re going to be closer to the mark than most. Allison Randal is a member of the core team designing Perl 6 the language; Dan Sugalski is the project leader for Parrot and Leopold Tötsch, generally described in my Perl 6 Summaries as the Patch Monster has a phenomenal work rate and knows Parrot inside out.

The book opens with a short overview of the genesis of Perl 6 and how the project is structured and managed, and how you can get involved in the various subprojects. Included in this section is an overview of how Perl 6 the language is being designed. One of the criticisms that’s been levelled at Perl 6 is that it’s being designed by a committee. However, this isn’t the way most of the people involved in Perl 6 see it. The language is being designed by Larry Wall, with direct support from Damian Conway, Allison Randal and the others on the core team. Meanwhile mailing list participants pitch in with new ideas, questions, clarifications etc. It might look like there’s a lot of noise and disparate voices if you’re watching the mailing lists, but it’s very apparent from reading the design documents that Larry puts out (The Apocalypses) that Larry is the designer of Perl 6. There’s a distinctive Wallian feel to them that’s very different from the stuff produced on the mailing lists, and even from the stuff Damian Conway did in his Perl 5+i effort. It’s quite weird—often I’ll see an idea on the mailing list and think “No, that’s just going too far.”, then along comes Larry in the next Apocalypse and he’s taken the idea I’d previously rejected, pushes it even further and comes back with something that’s powerful, Perlish and broadly useful.

Ahem, I digress.

Next up is an overview of the Perl 6 design philosophy. If you’ve seen Allison speaking about this at OSCON or YAPC then much of the material in this chapter will be familiar (I do find myself wondering which came first, the talk or the chapter²). This is a well written, thoughtful explanation of the principles underlying the language design. In a sense, this chapter can be thought of as an essence of Perl - There is very little in here that doesn’t apply equally to earlier Perls, possibly right back to Perl 0.whatever. Even if you’re not particularly interested in Perl 6 (or even Perl) there’s a good deal to think about here - the importance of considering natural languages when designing programming languages, and of giving the program the freedom to express her intent in several ways (and the responsibility to choose the clearest option of course)—there’s certainly plenty of meat for the Lambda the Ultimate and LL1 crowds.

Chapter 4 covers the syntax of Perl 6. It’s written as if it’s an early draft of the Perl 6 edition of Programming Perl. I really like this chapter, it covers an awful lot of ground and it does so with admirable clarity. The most obvious change is Larry’s total rethink of the pattern matching syntax, which is a fantastic piece of work and no mistake, but a no less important change (to my way of thinking at least) is the changes in the way blocks work.

If you listen to the likes of Mark Jason Dominus (and if you don’t listen to Mark, you really should) you’ll be aware of the importance that he places on Perl’s very high level capabilities, particularly its functional programming capabilities. Well, in Perl 6, functional programming just got a whole lot less wordy. And with tail call elimination on the cards, it should be getting faster too.

The shift to function signatures which name the arguments helps to reduce the ‘noise’ in the body of the the subroutine. Hoisting parameter naming into the signature gets rid of all the tedious manipulation of @_ that characterises every single subroutine block in Perl. I sometimes think that the parameter handling folderol is one of the main reasons that too many Perl 5 functions and methods stay long and don’t get factored into small, comprehensible units of code.

Perl 6 has also dropped the requirement to use sub to declare anonymous subroutine, making it far easier to write methods and functions that can be used as if they were part of the language. And hey, it’s four characters less to type every time you call a higher order function or method. It doesn’t sound like much, but if you go and take a look at Ruby or Smalltalk and the way in which so many of those languages’ powerful constructs make heavy use of syntactically light³ blocks. See Exegesis 6 for a very good set of examples covering almost everything to do with subroutines, methods and blocks.

Also in this chapter is coverage of Perl 6’s replacement for Perl Compatible Regular Expressions. Wow. If I were a Python or Ruby evangelist, then I’d currently be busy stealing the ideas and syntax in the new Perl 6 Rules and trying to get something up and running before Perl 6 does. The new Perl 6 Rules/Grammar system is a comprehensive rethink of how pattern matching works and should work. As I’ve mentioned in an earlier entry, I went to Damian Conway’s talk on Perl 6 Rules at OSCON this year, and he showed off a partial implementation (in Perl 5) and they’re phenomenal parsing tools. That afternoon, I rode in Ward Cunningham’s Jeep back from Portland Zoo and we talked about Perl 6 rules. I may not have got my Ward number down to 1 at OSCON, but I can say that Ward seemed excited by the possibilities inherent in the new rules system. He’s not alone.

The rest of the book is concerned with Parrot, Perl 6’s target VM(Virtual Machine). Unlike Perl 6, Parrot is available to download and run today. It’s not finished, but it’s becoming more capable as every day passes (thanks in no small part to Leo Tötsch’s phenomenal workrate, and, in recent weeks, Michal Wallace’s sterling work on getting Python up and running on Parrot). This does mean that the Parrot section of the book has a few inaccuracies where Parrot has changed the way it works. My favourite is found in the discussion of Coroutines on p93 where Dan writes “Coroutines can be implemented in terms of continuations if need by, but that requires using a full continuation-passing function call system, something we choose not to do”. Well, that’s what most copies say; Mine has a signed correction from Dan as I believe that particular statement was out of date about a day after too book went to press. There aren’t many of these however, and I’d be worried if there weren’t any—good design arises from experience, and there aren’t too many people with experience of writing a register based VM. Overall, the Parrot Internals chapter is strong on the structure of Parrot, and offers insight into the why of it. If you intend to help with the task of implementing Parrot then this is an excellent place to start; you’ll still have to read the source, and the detailed design documents, but if you’ve read this you’ll have a good map in your head of how things hang together.

The last two chapters are concerned with writing assembly programs to run on Parrot. Essentially the would be language implementer can either write all his code in native Parrot Assembly Language, managing register allocations and the like himself and generally getting all those associated headaches. Or, he can write code for IMCC using Parrot Intermediate Language (known as PIR for reasons that aren’t entirely clear even to one who has been watching the mailing list since the Parrot project started) which is an ‘overlay’ on top of PASM. IMCC handles all your register allocation needs, implements macros, handles the parrot callling conventions and generally makes the poor compiler writer’s life easier. The idea is that IMCC will provide language independent optimizations such as automatic inlining of function calls, loop unrolling and (eventually) the whole arsenal of assembly level optimization tricks that have been developed down the years. All you have to do is write your compiler/interpreter reasonably simply and let IMCC handle the bookkeeping. But, I’m getting ahead of myself again.

Reading the chapter on Parrot Assembly Language can be a strange experience, especially if you’re used to ‘real’ assembly languages. It starts off gently, looking pretty much like ‘real’ machine code, but with the odd wrinkle that there seems to be no way of accessing the main memory, and there’s PMCs to worry about that don’t look like anything you’d get in a ‘real’ assembler—what was the last chip you saw with a fully functioning sprintf opcode? The chapter finishes with a handy reference of Parrot ops and how to use them, which is excellent; I generally don’t have sufficient screen real estate to go tracking through doc files in search of something, but a book open beside you is a godsend. Parrot Assembly is a remarkably powerful and expressive assembly language, but for anything serious you should really press on to the next chapter, which covers IMCC.

IMCC is great. Although it was intended as a target for compilers that didn’t want to have to worry about the register allocation bookkeeping, it’s also a very pleasant environment in which to write your own code. Again, this section of the book is well written and makes a very handy reference. Last but not least is a decent index (given the speed with which this book was put together I’m amazed that it has an index, let alone a decent one.)

Perl 6 Essentials has had a somewhat mixed reception in various places. The major criticism (from those who have neither read it nor intend to read it) is along the lines of “Even by the most optimistic estimates, Perl 6 is at least a couple of years away, why do we need this book?” Well, yes, Perl 6 is at least a couple of years away, but Parrot (or something very like it) is here right now and it’s supporting some ‘real’ programming languages, not just toys like BASIC and Python, it can even host Brainfuck and Befunge. If you want to start targetting Parrot, then this book is a great place to start.

The Perl 6 half of the book is important too. Allison has pulled together the existing Apocalypses and Exegeses, taken the various changes that have happened since they were written and boiled the state of Perl 6 down into a straightforward and readable description of where we stand. From the feedback I’ve been getting about my weekly Perl 6 Summaries, I know that there are plenty of people out there who are interested in what’s going on in Perl 6, but who don’t have the time to read the mailing lists. I don’t doubt that there are also people out there who are interested in Perl 6 but who don’t have time to read the summaries for whom this book would also be ideal.

I do wish it had larger margins though. I can see this becoming a book that I end up covering with annotations and addenda as the language changes with each new Apocalypse, Exegesis, Parrot Design Document and large patch from Leo Tötsch. And I do wonder if it wouldn’t have been better entitled The Perl 6 Annual 2003.

¹ Parrot is the register based virtual machine that will host Perl 6.

² Ah… I just got mail from Allison, the chapter got done first and the process of writing it inspired the talk.

³ By which I mean blocks are introduced with a minimum of gubbins, no keywords required.

The Quality Without A Name

pdcawley@bofh.org.uk (Piers Cawley) — Tue, 29 Jul 2003 06:06:00 -0500

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

The Fundamental philosophy behind the use of pattern languages in buildings is that buildings should be uniquely adapted to individual needs and sites; and that the plans of buildings should be rather loose and fluid, in order to accommodate these subtleties.

[An essay describing the problem more fully, and the reasoning behind the solution presented]

Therefore:

Recognize that you are not assembling a building from components like an erector set, but that you are instead weaving a structure which starts out globally complete, but flimsy; then gradually making it stiffer buit still rather flimsy; and only finally making it completely stiff and strong. We believe that in our own time, the most natural version of this process is to put up a shell of sheet materials, and then to make it fully strong by filling it with compressive fill.

Look, Agile Building!

Alexander and his co-writers have found a remarkably powerful way of managing complexity by isolating parts of the process of building in individual patterns, but neatly tying them into the greater whole by their use of introductory and closing paragraphs to explain the context in which a pattern is used. When I read it, I find I’m constantly flipping back and forth to look at these contextual patterns that support (or use) the pattern that I’m concentrating on. The book itself has the Quality Without a Name.

It was only after I’d read The Timeless Way and A Pattern Language that I came across the idea of Design Patterns in programming (In fact, I was working as a contractor and had a copy of The Timeless Way on my desk when a coworker spotted it and made a remark along the lines of “Ah, going back to the source eh?”, which he then had to explain as I didn’t know what he was talking about.) when a friend lent me the Gang of Four’s Design Patterns.

I don’t really like Design Patterns. Too many of the patterns seem to be concerned with working around problems with the static nature of C++ and Java—not exactly useful if you’re used to a more dynamic OO language. Another, deeper failing, is the disjointed nature of the patterns presented; there’s no attempt to tie the patterns together in a coherent language and the whole thing feels like a mishmash of ideas waiting to be turned into a finished book.

There is one software patterns book I’ve read that gets it though, that has The Quality Without A Name in the same way that A Pattern Language does. That book is Smalltalk Best Practice Patterns by Kent Beck. If you don’t know Smalltalk, don’t be put off by that title; a very sizable fraction of the book can be applied directly to any suitably dynamic OO language (Perl, Python, Perl 6, Javascript…) and the syntax of Smalltalk is virtually nonexistent and easy enough to pick up.

The book works well because Beck, quite deliberately, limits its scope to the tactics of coding. Instead of going for the big things, we’re dealing with the nuts and bolts: how to choose good names, how to write methods in ways that encourage reuse and flexibility, how to keep things loosely coupled. Beck explains this stuff with concrete examples and simple rules, that work phenomenally well together. It’s hard to put my finger on why it works so well, but my gut feeling is that it’s because Beck has not forgotten the importance of context.

Very few of the patterns are strictly standalone, they refer to each other up and down the ‘levels’ of the various patterns and the individual patterns are small enough, and well enough supported by the other patterns in the language that they remain tightly focussed on the issue they address.

Smalltalk Best Practice Patterns is a complete pattern language, something that I’ve not seen achieved in any other software patterns book (though Martin Fowler’s Refactoring: Improving the Design of Existing Code gets pretty close.) It’s easy to read; full of practical wisdom from someone who knows their stuff and can explain it well.

I recommend this book wholeheartedly to anyone who wants to become a better programmer, and especially to anyone who does object oriented programming in a dynamic language of any kind. If you find me in a bar amongst programmers, and we’re talking about how to get better at our craft, then I’ll almost certainly be banging on about how good this book is.

I believe the Java types are fans too, but if I were a java programmer then I’d find the kind of flexibility inherent in Smalltalk as expressed in this book would just make me want to abandon Java in favour of something more expressive.