clarifications on trailblazer [07/18/2007 04:12:45]

s/plan/trail/g;

I've realized that implementation plan is the wrong word.

It starts out as a plan, but you keep adding information to it as you go, so in the end it's not a plan but a trail.

A subset of literate programming

Also, yesterday's post made the programming.reddit and someone said it sounded like I literate programming.

Narrative code is a literate programming genre but the ideas are not equivalent.

Every piece of literate code I've seen (including Knuth's early paper) explains how things work in their final form. What I'm talking about is a document that describes how things got to be this way.

A simple use case would be porting the code to another language. You could start on the first line of an implementation plan and port it line by line, and you'd know exactly what to expect along the way.

With literate code, it isn't necessarily linear in this way. The author could start with a high level tour of the code and leave the actual implementation to the very end. In that case, if you wanted to port the code to a new language, you'd have to do some unraveling to figure out where to start.

Narrative is a programming style, Trailblazer is a methodology.

I didn't invent narrative code. There are actually quite a few examples in recent programming books. Fowler's Refactoring has a long narrative at the front. Beck's Test Driven Development by Example is almost entirely told in that style. Online, the bowling score article comes to mind.

In these examples, you watch the code develop before your eyes. Narratives like these really sold me on extreme programming, but eventually I realized it was the narratives that held the magic, not the endless refactoring in lieu of planning and design.

I started to wonder why you couldn't write all code that way. It's only because the tools don't exist yet.