Alec Nevala-Lee

Thoughts on art, creativity, and the writing life.

Posts Tagged ‘Dennis Ritchie

The recursive art of fiction

with 3 comments

Quicksort

One of the most striking things about writing fiction is how the strategies you apply to the highest level of story often work on the smallest pieces as well. Take, for instance, one of the most basic rules of craft: start the story as late in the action as possible, and end it as soon after the climax as you can. In the rewrite, jumping in late and getting out early sometimes means cutting pages from the beginning and end to remove extraneous material, or engaging in slightly more sophisticated surgery: the pulp novelist Jack Woodford, in two brilliant pieces of advice I’ve quoted here before, notes that you can keep much of the “the usual driveling collection” of exposition and anticlimaxes if you restructure the novel so that the real beginning and end come before and after the boring parts. The same rule applies to individual chapters, scenes, and beats. William Goldman famously advises writers to omit the beginning and end of each scene so the story jumps from middle to middle, and I’ve often fixed a sequence of chapters that didn’t work by cutting the first and last paragraphs of each.

In other words, a rule that works for the overall shape of the story also helps you make decisions about the structure of its smallest components. This isn’t so far from the principle of recursion as understood in computer science. Recursion means writing a function—a set of instructions—that at one point in the process calls on itself to deal with a subset of the larger problem. The most famous example is Quicksort, the sorting algorithm developed in the sixties by C.A.R. Hoare. Quicksort begins with a string of numbers to be sorted, picks one number at random from the middle of the string, then sorts the entire list into two parts, with all the larger numbers in one half and the smaller ones in the other. Then it applies itself to each smaller piece, dividing and sorting until a subset has fewer than two elements, which means we’re done. And although recursion doesn’t always result in saving time or storage, it’s a useful way to think about problems, as Kernighan and Ritchie note: “Recursive code is more compact, and often much easier to write and understand, than the non-recursive equivalent.”

Quicksort tree

That’s the benefit of a recursive approach to fiction, too: it tackles big problems in ways that are intuitively easier to understand because you’ve already used them on a lower level, and vice-versa. I’ve found that when a novel gets off track, it’s often because the writer has gotten lost in the weeds: you get hung up on little details—like how to get a character out of a room—until you’re so close to the problem that you can no longer see it. The solution is to remember that each chapter, scene, or paragraph is really a story in miniature, and it can be hacked in the same way you found the novel’s three acts. A recursive set of rules for writing fiction might look something like this, starting at the level of the story as a whole and working your way down:

  1. Divide the narrative unit into three parts. (This is usually a matter of intuition, and, like choosing the initial element in Quicksort, it doesn’t really matter at first where you draw the lines. We divide the story into three parts, rather than two, in deference to the rule of three.)
  2. For each unit, figure out the protagonist’s objective and the action he or she needs to take to achieve it.
  3. Repeat for each subsidiary unit until it can’t be divided any further.

In practice, this means that the story as a whole falls into three acts; each act falls into three sequences, with each one consisting of, say, ten chapters; each sequence yields three smaller sequences; each chapter has its own beginning, middle, and end; and so on down to the level of the page and paragraph, until you’re down to a single beat—a unit of narrative that can’t be divided any more. For that beat, you find the protagonist’s objective and concrete, physical actions, which, when taken together, add up to the overall objective for the scene, all the way up to the superobjective for the novel as a whole. (This way of breaking down scenes into beats and thinking in terms of objectives is more fully explored in David Mamet’s On Directing Film, which does for storytelling what The C Programming Language does for coding.) Put this way, it may sound mechanical, and it is: in practice, it’s more of a dialogue between the writer’s intuition and rational mind, as you try to fit in scenes that have seized your imagination into the overall logic of the narrative. Like coding, it’s rarely as neat in practice as in theory. But thinking about it recursively helps us remember that the rules at the top are often the same as the ones at the bottom.

Written by nevalalee

August 19, 2013 at 9:31 am

A writer’s code

with 3 comments

Anagram generator from Foucault's Pendulum

One of the small pleasures in writing this blog—and in particular in coming up with the quotes of the day—has been a renewed appreciation of the affinities between writing fiction and computer programming. There’s a remarkably rich body of literature on the art of coding, and simply by browsing through the available works in search of memorable insights, I’ve come to realize that coders deal with many of the same problems that I’ve had to confront in my novels, especially structure, clarity, and managing complexity. Hacking, like writing, requires a balance between formal elegance and quick and dirty fixes, and a coder is often required to choose between ingenuity and readability: a clever solution may be beautiful in the moment, but it can be all but impenetrable if the author—or anyone else—comes back to pick it apart months or years later. And unlike novelists, coders get immediate feedback on the validity of their solutions from a rigorous, if somewhat unimaginative, reader.

The problem is that I haven’t done a lot of hacking on my own. Growing up, I spent hours messing with BASIC on an ancient “portable” computer that didn’t even have a hard drive. (My earliest program, written when I was thirteen or so, involved expanding the anagram generator that Umberto Eco provides in Foucault’s Pendulum to handle words of more than four characters.) Later, I took a computer science class or two in high school, but I haven’t done anything meaningful since.  More recently, I’ve found myself longing to jump back into programming for a fairly specific reason: not to do any serious coding of my own, and certainly not to get paid for it, but simply to gain access to the enormous amount of material written by coders on how they approach their work. Compared to the handful of well-worn tidbits that writers repeatedly invoke on craft, it strikes me as admirably pragmatic, dense, and varied, and even at a glance, it clearly has elements that I can put into practice.

A snippet of source code from Doom 3

This leaves me with the question of which language to learn, an issue that inspires predictably strong opinions on all sides. Not surprisingly, I made the final call based on the books I wanted to read. At the moment, I’m working through The C Programming Language by Dennis Ritchie and Brian Kernighan, which is generally regard as the best book of its kind, and I’m planning to follow it up with The Design and Evolution of C++ by Bjarne Stroustrup, which is one of those extended looks into a sustained design process that I find so irresistible, whether the subject is writing, animation, or cuisine. C and C++ might seem like odd choices for recreational coding, but they’re useful for my purposes because there’s so much source code available, along with what I can only describe as a highly specialized form of literary criticism, like Shawn McGrath’s recent appreciation of the beauty of Doom 3. There’s a whole world of material out there, and I’ve found that it only takes a little work to start to appreciate the basics.

Once I’ve played with C and C++ to my satisfaction, I’m hoping to jump into Lisp. This might seem like another strange choice, and I hope to explore it further in a future post. Suffice to say that Lisp, like C, offers a range of interesting reading material, from Paul Graham’s books on the subject to Douglas Hofstadter’s three essays in Metamagical Themas to Peter Seibel’s Practical Common Lisp. (Seibel, a former English major, is also the author of Coders at Work, which attempts to do for hacking what the Paris Review interviews did for fiction.) Lisp also strikes me as the most novelistic programming language, and the one with the greatest natural affinities to creative writing—but we’ll see. When you’re a writer, you’re always looking for tricks that your peers haven’t discovered yet, as well as any source of insight or competitive advantage, and given my interests and approach to craft, I think a deep dive into coding is the next logical step. Whether or not it yields anything useful is something I’m still waiting to find out. But if it does, you’ll be reading about it here.

%d bloggers like this: