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

61–70 of 140 posts

Re: Thinking about recipe formats more than anyone should

#61

Post by stevage »

account42 wrote: post #60
stevage wrote: post #47

Earlier quoted context omitted.

Some recipes end up with more than one dish, like when you prepare a thing and its accompanying sauce together. I guess superficially you can join them together with a final node that is like "serve all the dishes".

You also often have ingredients or intermediate products that are used in more than one step so a tree is not ideal. You could duplicate those ingredients/intermediates but that would not be helpful. And for more complex meals, time planning becomes more important so that everything is ready to serve together.

To be honest, I kind of prefer when a recipe treats duplicate ingredients as completely separate. Rather than that "use 300g of the butter here, use the rest here" approach which is harder to follow.

Re: Thinking about recipe formats more than anyone should

#62

Post by account42 »

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…

> (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?

Re: Thinking about recipe formats more than anyone should

#63

Post by Xelbair »

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 you some compound ingredients(stocks for example) as side-output that you might want to use in future!

This is a great case for using that information for planning future dishes you could cook for free.

Re: Thinking about recipe formats more than anyone should

#64

Post by njtransit »

Perhaps it’s just me, but I’ve cooked recipes off of 50 year old, grease stained index cards written in barely legible cursive, whose ink has all but rubbed entirely away. And it was fine. Worrying about recipe format is like trying to improve reading as a technology. The state of the art is both really simple and really old. It’s hard to mess up (format-wise, recipe content can definitely suck) and it’s hard to improve.

Much more important to me: is the listed cooking time of onions accurate.

Re: Thinking about recipe formats more than anyone should

#65

Post by account42 »

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

Duplicating the nodes is also far from ideal when the reused node is not a raw ingredient but an intermediate with possibly complex dependencies itself. Duplicating the whole subtree would not be helpful.

Re: Thinking about recipe formats more than anyone should

#66

Post by ClaraForm »

Swizec wrote: post #33
chuckl wrote: post #30

Earlier quoted context omitted.

I think of them as 2 different nodes, 2 instances of the same type of ingredient. Practically I just have it listed twice if it's important like butter. https://cookbook.cstebbins.com/recipe/the-best-swedish-meatb... otherwise if it's a staple like salt I just say something like "stir in and season with additional salt and pepper to taste" like in https://cookbook.cstebbins.com/recipe/sloppy-sophisto-joes

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

What if there was one further section in the left column that runs across the y axis and tallies ingredients?

That way there are three "segments" of the spreadsheet: shopping; prep; cooking.

Re: Thinking about recipe formats more than anyone should

#67

Post by kiru_io »

telebell wrote: post #44

Here's my favorite format, which my sister and I made. It doesn't work well for all recipes, but it does for lots of them. Minimizes words, easier to visualize steps. https://imgur.com/a/RDO6j6H

This looks very close to the table-format from Cooking For Engineers®: https://www.cookingforengineers.com/recipe/320/Sauteed-Spina...

Re: Thinking about recipe formats more than anyone should

#68

Post by kiru_io »

irrational wrote: post #41

What about the table format used by https://www.cookingforengineers.com/ ? Though, tables in markdown are not so easy to read unless you put effort into formatting the data.

I was looking into the table format for my app[0], but then the notes at the end made me reconsider: Tabular Recipe Notation Patent Pending (Michael Chu)

[0] https://news.ycombinator.com/item?id=42036041

Re: Thinking about recipe formats more than anyone should

#69

Post by eulgro »

DavidPeiffer wrote: post #51

Since people are posting their respective recipe formats, I'll throw in one created by a friend from college. I haven't tried any recipes in this format, but the color coding of processing/ingredient blocks to the vertical time axis and clear listing of how ingredients get processed together are appealing. I've had multiple recipes on common recipe sites in which, mid-cooking I've realized were missing steps, didn't…

This is how I do it. I can't stand needing to find information in ten paragraphs of text while cooking.

- Ingredients are listed in one column on the left in order of use.

- Duplicate ingredients are separate.

- Each step has one or more input products and one or more output products, indicated by arrows, and braces to group multiple.

- Handwritten because it's much easier. Computers are just too much trouble.

Re: Thinking about recipe formats more than anyone should

#70

Post by TeMPOraL »

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'd start with a DAG.

In fact, going through a project management basics training at work recently reminded me that cooking recipes are isomorphic to project plans. Which makes DAGs an obvious natural representation for a recipe, and incidentally, makes the Gantt chart one of the best ways of looking at it.

Post reply on HN