Hacker News new | ask | show | jobs
by eru 588 days ago
Well, it would be more like a directed acyclic graph, not a tree, because you can re-use nodes.

(And it's not even necessarily acyclic, because eg sourdough or master stock is perhaps best modelled as a cycle.)

In any case, looking at a recipe as a tree or a graph is a very limited view:

A great recipe isn't a list of steps to produce 'something'. A great recipe has a dish in mind with a specific taste (or a specific family of tastes with knobs you can turn), and the author has worked out what parts of the recipe you need to adapt in what ways to compensate or take advantage of current local conditions.

Eg some days it's warmer than others, so you need to adjust your fermentation times. Or some parts of the world have harder water than others. Or your available veggies might have different amounts of moisture etc.

2 comments

From a slightly pedantic point of view that misses the point of cooking or baking, I disagree about the ability to re-use nodes.

If you have a recipe that uses 150g flour in step 1, then later uses 350g flour in step 4, then you actually have two separate ingredients:

1. 150g plain flour

2. 350g plain flour

It may useful to present an ingredient summary for the purposes of shopping which collects that to 500g flour, but from when trying to represent the recipe, it's actually two different ingredients, and it'd be a false re-use to try to re-use the node or try to treat those ingredients as a single ingredient of greater quantity.

Just because two things appear otherwise identical, doesn't mean they are.

I sometimes see a similar issue in software development and re-use of classes or functions. Two different cases happen to need identical handling, so get put through the same code paths. Then later it turns out one case needs to be treated slightly differently, so that path ends up with special casing, and you get a mess of special handling with case statements or "bool treatDifferently" parameters.

If things are conceptually different, then treat them differently, don't assume false commonality.

Well, you need to be careful what your graph and nodes are supposed to model.

I was implicitly assuming that your graph models instructions and procedures. You seem to assume that the graph models concrete physical items.

You can execute the same steps twice, but you can't eat the same piece of butter twice.

It's a bit philosophical, but I'm not sure you can really execute the same steps twice. A cycle would imply you can get stuck baking something forever.

When you come back to do the "same" operation again, you're fundamentally dealing with different items, even if it doesn't appreciably appear to be the case.

You might have different criteria for evaluation, but something has fundamentally changed.

Let's look at the simplest case you might be tempted to model as a cycle:

> "Salt to taste"

Now, that would traditionally be modelled in a flowchart as a cycle:

1. Add salt

2. Test taste. Too little salt? Go to step 1. Else go to step 3.

3. End.

However, in strict modelling terms, I'd argue there's a hidden parameter, "number of saltings attempted".

You wouldn't repeat that a hundred times and keep adding salt, after a while you'd suspect that your taste-buds had gone or the salt had gone funny.

So rather than a cycle, it's actually a series of steps with a hidden step counter, which eventually has different outcomes.

I'm glad you figured out that the graph is a model, and like any good model, it picks some characteristics of reality to keep and many to leave out.

Have a look at the example of a turnstile state machine on Wikipedia: https://commons.wikimedia.org/wiki/File:Turnstile_state_mach...

The graph of that state machine suggests that you repeat the cycles indefinitely. But I have it on good authority that real world turnstiles only have a finite coin box. [citation needed] So there's some extra hidden state.

You'll also need to break up intermediate products. An egg breaks down into yolk and whites. Whites may be used for different purposes, one of them foam. Foam might be broken down further.

Recipes are not a tree.

See my comment in another thread about this topic:

https://news.ycombinator.com/item?id=41700416

In particular the lemon meringe pie. You separate whites and yolks to prepare the filling and the meringue separately before merging them in the last step.

>it'd be a false re-use

Technically, recipes are monoidal pre-orders and I guess you could find arguments against what you propose in the mathematical foundation, unfortunately I'm not versed enough in category theory to articulate it properly.

Separating the eggs is a great example!
> From a slightly pedantic point of view that misses the point of cooking or baking, I disagree about the ability to re-use nodes.

For example, if you make the "Lobster, Poached with Shellfish, Pear, and Kale" from the 11-madison park cookbook, you will make a "white balsamic vinaigrette" which is then used directly to make the "Pear Glaze", "Pickled Mustard Seeds", and "Pear marmalade" components. (The pickled mustard seeds also go into the "Pear marmalade" component.)

> if you make the "Lobster, Poached with Shellfish, Pear, and Kale" from the 11-madison park cookbook, you will make a "white balsamic vinaigrette"

I think the post you're replying to is saying that you'll make 3 "white balsamic vinaigrettes" instead of reusing the same one 3 times.

Which makes sense since one step of the recipe will be to divide the vinaigrette into 3 amounts to make the other ingredients.

No, you make a larger amount of liquid, and then you divide it.

You'd only have one node. Just like you don't put every bite of food into its own node.

you can divide it into multiple containers, where they become multiple objects, each participating in a different (sub)recipe. node as use of unit-item, not the physical bunch of item itself. instance, not type.
Depending on what you want to model, either view can make sense.
> (And it's not even necessarily acyclic, because eg sourdough or master stock is perhaps best modelled as a cycle.)

So what you are saying is that cooking instructions need phi nodes?