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

101–110 of 140 posts

Re: Thinking about recipe formats more than anyone should

#101

Post by groby_b »

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

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.

Re: Thinking about recipe formats more than anyone should

#102

Post by buescher »

This hurts a little to read. Think about the use cases for recipes:

- Shopping

- Scaling up/Scaling down

- Finding ratios of key ingredients when you're looking at multiple recipes to figure out a dish or what's wrong with the last recipe you tried

- Mise en place, which is conventionally omitted except in very detailed recipes

- Planning cooktimes

- The actual cooking process

And as a home cook, I'm not personally experienced with commercial use cases, but there's even more there: costing servings, menu planning, mise across several dishes with common ingredients, etc. Having seen some commercial recipes, pros will frequently use very simple lists of ingredients and just a few notes on technique. Bakers will use baker's percentages.

The weird "cooking for people who insist on modeling the world in complicated categories" format doesn't support these very well, but it sure helps with "is grinding the whole spices a substep of combining the spice mixture?".

Re: Thinking about recipe formats more than anyone should

#103

Post by winkywooster »

buescher wrote: post #102

This hurts a little to read. Think about the use cases for recipes: - Shopping - Scaling up/Scaling down - Finding ratios of key ingredients when you're looking at multiple recipes to figure out a dish or what's wrong with the last recipe you tried - Mise en place, which is conventionally omitted except in very detailed recipes - Planning cooktimes - The actual cooking process And as a home cook, I'm not personally e…

another to add to the list is high-altitude modifications. using mark bittman’s guidelines ingredients and temperatures become a function of altitude. recently i’ve been using llms to make the modifications for me.

Re: Thinking about recipe formats more than anyone should

#105

Post by renewiltord »

beAbU wrote: post #92
irrational wrote: post #43

Earlier quoted context omitted.

Here is an example from Cooking for Engineers - Lemon Bars. If you scroll down to the recipe you can see it uses all-purpose flour twice and lists it two times on the left side of the table. https://www.cookingforengineers.com/recipe/33/Lemon-Bars

This makes it real hard to determine the total amount of flour needed. Maybe add another column to the left, that sums up all the ingredients, in the format you might get it at the store. Then the second column becomes the mise en plas step, where the base ingredients are divided and prepared/chopped/grated etc. Problem is column 1 and 2 wont necesarily have ingredients on the same row...

Left columns is raw ingredients no? LLM did perfect job with summing it. This is like instruction plate not shopping list. Can transform trivially.

Re: Thinking about recipe formats more than anyone should

#106

Post by buescher »

winkywooster wrote: post #103
buescher wrote: post #102

This hurts a little to read. Think about the use cases for recipes: - Shopping - Scaling up/Scaling down - Finding ratios of key ingredients when you're looking at multiple recipes to figure out a dish or what's wrong with the last recipe you tried - Mise en place, which is conventionally omitted except in very detailed recipes - Planning cooktimes - The actual cooking process And as a home cook, I'm not personally e…

another to add to the list is high-altitude modifications. using mark bittman’s guidelines ingredients and temperatures become a function of altitude. recently i’ve been using llms to make the modifications for me.

Or adapting to specific dietary requirements.

Simple formats and clear written language go a long way for human use cases.

Re: Thinking about recipe formats more than anyone should

#107

Post by buescher »

JoshMandel wrote: post #5

I find "higher level" format issues to be of greater concern. These are issues like: is the recipe structured in a way that makes the prep/process flow clear, makes it obvious when a certain ingredient needs to be prepped but divided into multiple parts for use in different stages, or when different stages lead to products that are combined and subsequent poisons in the workflow? A recent example: I really like the H…

I gave your example the instruction "Reformat in two-column format, with the ingredients listed on the left side as they are used" (i.e. the style used in Julia Child's _The Art of French Cooking_) and chatgpt failed horribly.

Re: Thinking about recipe formats more than anyone should

#108

Post by dunham »

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

> 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.)

Re: Thinking about recipe formats more than anyone should

#109

Post by RandallBrown »

dunham wrote: post #108
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,…

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

> 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.

Re: Thinking about recipe formats more than anyone should

#110

Post by _randyr »

I've also been thinking entirely too much about a good recipe structure.

For now I've ended up on ingredients being more or less recipes themselves, and recipes being recursive (as in, recipes use other recipes to create new recipes). Some recipes you can either buy & make yourself. For example, sweet soy sauce: easy enough to make but you could also just buy it in the store. The resulting structure is basically:

  Recipe:
    directions: rich text
    storageInstructions: rich text
    prepTime: minutes
    cookTime: minutes
    priceEstimateperServing: money
    ingredients: RecipeIngredient[]
    // other fields (e.g. tags, id, name, slug, purchaseableAt, nutrients, etc)

  RecipeIngredient:
    recipeId: reference to recipe
    ingredientId: reference to recipe as well
    // Allows grouping ingredients (e.g. "sauce", although the sauce could be a recipe of its own instead)
    group: string | null
There's some challenges with this though:

- If you have a shopping list, how do you determine in a complex recipe which "recipes" you'll purchase and which you'll make from scratch (UX issue)

- Some recipes may have alternatives instead (for example: if allergic to X, substitute with Y)

- It puts a lot of burden on the recipe writer.

- Some recipes don't scale linearly with just the ingredients, but perhaps also the cookware (baking a cake for example). Cooklang docs talk about this as well.

Scaling of recipes could be done with a measurement-aware type. Something similar to frinklang[0] for example.

[0]: https://frinklang.org/

Post reply on HN