< Previous
Yum Yum Yam Yam Walla Walla Couscous >

[Comments] (2) How to think about recipes: I have a brilliant plan to make money off of the ideas I'm going to synthesize in this entry, but others are catching up to me on the basics and I still haven't done anything with my alleged plan that's so great. So this is kind of my admission of defeat; I'm going to try to formalize and make obvious the part that's about to become well-known anyway.

Let's think about recipes. Every time you make a recipe you perform a ritual corresponding to the recipe. A recipe is generally written as a narrative, but except in very simple cases you never make the recipe simply by reenacting the narrative. If you want to get it done in a reasonable time (and, if heat is involved, if you want it to work at all), you have to set multiple things going simultaneously, the ordering merely hinted at by the use of words like "meanwhile" in the recipe.

Even when the recipe is divided into sub-recipes, you need to read the recipe as a whole and figure out how best to use your time, what the prerequisites are, and how the recipe will take shape. The idea of mise en place is, in my opinion, partially a hueristic to make this step easier by moving a lot of the decisions to the front so you don't have to place them elsewhere.

That's the state of the art. Now imagine writing a recipe for a hypothetical cooking robot, something that knows about ingredients and cooking techniques but lacks planning skills. You'd get a representation similar to one you'd find in an MMORPG cheat-sheet. This representation describes the recipe in terms of the ritual, depicting a series of steps in which you combine and transform old items to get new items. I bumped into this idea a year ago, the way a ship might bump into a mola mola, but didn't actually understand that it could be used to represent real recipes until I played Kingdom of Loathing.

These recipes look like trees. The vertices of the tree are items of food. The leaves are the ingredients, and at the root lives the finished dish. The edges of the tree are operations. Some of them are unary (melt the butter), some are binary (brush the dough with butter).

This is the cool part. You can do all sorts of things with a tree representation of a recipe. Some of them have to do with the fact that your representation represents the cooking ritual, and some have to do with the fact that the ritual is now computer-parsable.

The more complicated actions now naturally correspond to a longer branch of the tree, making it easier to get a feel for how the recipe ritual is going to go. If you have times associated with each operation, you can calculate which actions you need to start first. You can, if you know enough about ingredients and their properties, perform a transformation on the recipe. (This is the part I am really excited about.)

As far as I can tell, this idea originated in Computerized Cooking, a gloriously cranky but un-ignorable document from the '80s which reminds me of Ted Nelson's stuff. Recently it found new life in insta-hit weblog Cooking for Engineers, which does a lovely tree presentation that is a tree but doesn't look like a tree, or RPN, or have a lot of internal cross-references. The ugliness of the recipes was my main problem with Computerized Cooking, and I really admire the way CfE solved it.

So that is how, in my opinion, you should think about recipes if you want to make money from recipes (as opposed to food) in the twenty-first century. On a higher level of abstraction lives the meta-recipe of the culinary design pattern, which I think looks like a templatized recipe. And above it in a different direction you have the meta-recipe of the meal, which I still have no clue about. I think it would look like a set of recipes with interconnected techniques and ingredients, but I'm starting to sound like Frank Chu so I'll leave that alone until I figure it out.

Filed under:

Comments:

Posted by jack masters at Tue Sep 14 2004 01:36

Speaking of recipes, I had some ideas for new functions for the eater of meaning.

One would be to turn all the words into pallindromes. You could do this in a variety of ways, something that would recognize palindromic interiors to words and work with those would be clevelc. I mean, clever.

I guess I only had one, come to think of it! But I also think there should be an option that eats each word using a random operation from among the operations already programmargrop.

Posted by daniel hsu at Tue Sep 14 2004 12:33

you might generalize the representation to DAGs (e.g. if some product is used in multiple subsequent products).


[Main]

Unless otherwise noted, all content licensed by Leonard Richardson
under a Creative Commons License.