Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Thinking about recipe formats more than anyone should

rknight.me

Post reply on HN
Print view View original

81–90 of 140 posts

Re: Thinking about recipe formats more than anyone should

#81

Post by d--b »

chuckl wrote: post #15

Just finished my own overthinking of recipe structures. I figure that a recipe is more or less an upside-down tree! Where you start with a list of all the nodes (ingredients) Have a n:1 relationship with the next series of nodes (steps) until you finish at a single node (the dish you're trying to make) So instead of having a separate chunk of "here's my ingredients" and "let me repeat the ingredients and one by one i…

overthinking some more: your idea is great but it removes the one feature that classic recipes have: sequencing.

You can have the best of both world, though, if the branches in your tree had some kind of timing associated.

Like when you make lasagnas, the bolognese takes 1 hour to cook, while the bechamel takes less than 10 minutes. You need to have a way to say: "while the bolognese is reducing, make the bechamel"

Re: Thinking about recipe formats more than anyone should

#82

Post by neutronicus »

chuckl wrote: post #37
Swizec wrote: post #33

Earlier quoted context omitted.

> I think of them as 2 different nodes, 2 instances of the same type of ingredient. But this is inconvenient during the shopping step of the process. There you want all uses of an ingredient (possibly across multiple recipes) collapsed into 1 node.

for sure! The use case I'm solving for myself is easy lookup while I'm cooking which is different than the use case of me going shopping Maybe someday I'll add a feature to grab a shopping list. Could organise it into sections of the store and do a quick traveling salesman problem :D also due to the conciseness of the grid, it's also not great if you're making it for the first time

> The use case I'm solving for myself is easy lookup while I'm cooking

This is a constant source of stress for me cooking from cookbooks I otherwise like. I prefer to measure on-demand, and wish the steps would just duplicate the quantities of the ingredients "whisk in the olive oil (1/4 cup)" instead of "whisk in the olive oil" so I don't have to scan the list of ingredients and figure it out

Re: Thinking about recipe formats more than anyone should

#83

Post by xnorswap »

eru wrote: post #49
chuckl wrote: post #15

Just finished my own overthinking of recipe structures. I figure that a recipe is more or less an upside-down tree! Where you start with a list of all the nodes (ingredients) Have a n:1 relationship with the next series of nodes (steps) until you finish at a single node (the dish you're trying to make) So instead of having a separate chunk of "here's my ingredients" and "let me repeat the ingredients and one by one i…

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…

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.

Re: Thinking about recipe formats more than anyone should

#84

Post by Finnucane »

j_crick wrote: post #4
Finnucane wrote: post #2

A nice demonstration of how JSON is a stupid way to manage complex text documents. It is not clear why that would be better than an xml-type arrangement like cut your apple into slices Or even just plain text.

I was reading through this and caught myself thinking "man, if you want people to read your recipe then just write it", and for that plain text or some minimal markup still works wonders...

The reason plain-text markup exists is so that someone can write it, then have it be machine-translated into some more structured format.

Re: Thinking about recipe formats more than anyone should

#85

Post by jdgoesmarching »

woile wrote: post #73

Nice, I have also created a language for recipe based on cook-lang (I didn't use cook-lang because I was not convinced by the syntax). The language is called recipe-lang[0] and it powers https://www.reciperium.com Check it out, I've open sourced as well a syntax highlight for vscode, a cli for the terminal, a tutorial and a playground, and the wasm modules. I use the language for more than food recipes, see: https://…

What do you not like about cooklang? I’m in the early stages of building an app around it.

Re: Thinking about recipe formats more than anyone should

#86

Post by eru »

xnorswap wrote: post #83
eru wrote: post #49

Earlier quoted context omitted.

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…

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,…

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.

Re: Thinking about recipe formats more than anyone should

#87

Post by ValentinA23 »

xnorswap wrote: post #83
eru wrote: post #49

Earlier quoted context omitted.

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…

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,…

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.

Re: Thinking about recipe formats more than anyone should

#88

Post by chuckl »

Xelbair wrote: post #63
chuckl wrote: post #15

Just finished my own overthinking of recipe structures. I figure that a recipe is more or less an upside-down tree! Where you start with a list of all the nodes (ingredients) Have a n:1 relationship with the next series of nodes (steps) until you finish at a single node (the dish you're trying to make) So instead of having a separate chunk of "here's my ingredients" and "let me repeat the ingredients and one by one i…

I would say that it gets a bit more complex than that. some recipes can produce multiple related dishes, and some ingredients can have multi-step substitutions. So Graph would be a better representation. you could join multiple dishes into final 'abstract' dish to force it into tree-esque shape with some shuffling hopefully, but i think that's unnecessary limitation - especially if you consider that some recipes give…

100%

under the hood I have it more like a graph with levels. The traversal is from all of the "leaves" to a single node rather than from the head node towards the leaves as in a traditional tree. The upside-down tree is more for a visual for the reader.

At the moment I don't have a recipe that outputs 2 end states but entirely possible since it's more of a graph under the hood.

Re: Thinking about recipe formats more than anyone should

#89

Post by xnorswap »

eru wrote: post #86
xnorswap wrote: post #83

Earlier quoted context omitted.

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,…

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.

Re: Thinking about recipe formats more than anyone should

#90

Post by guhidalg »

infecto wrote: post #77
guhidalg wrote: post #32

Earlier quoted context omitted.

Take a look at my website, https://letscooktime.com/ and let me know what you think of the way I render recipes. There is an internal representation like this: 1. A recipe is composed of multiple components 1. A component is composed of ingredient requirements and steps 1. An ingredient requirement is a tuple of an ingredient and a quantity I found good success using this model for recipes, specially complex baking r…

For myself, the one thing missing the quantity of items inside of the recipe itself. I am often using my phone to read a recipe while cooking and its annoying to have to scroll back and forth to see how much of something I need to add. I have all the ingredients out and ready, just tell me in the steps how much of a seasoning I need to be adding.

Yes! Phone screens are too small to show both the instructions and the ingredients at the same time. To address that in CookTime, I highlight any instance of an ingredient found in the recipe instructions and show the quantity if you click/tap on it. I could change it to just show it unconditionally if that wasn't apparent when you looked at a recipe (like this one for example https://letscooktime.com/Recipes/Details?id=ed962bb3-64b7-42...)
Post reply on HN