Live data from Hacker News

Thinking about recipe formats more than anyone should

rknight.me

131–140 of 140 posts

Re: Thinking about recipe formats more than anyone should

#131

The replies to this post are, unfortunately, very indicative of the negative side of the "(pseudo-)engineering mindset", which is rather close to the model-constructing mindset inherited from economics (reductionism, hiding any variety incurred by real world complexity, etc). I don't see very many people here who seem to really have done a lot of cooking, consider it a serious hobby or profession, etc. None of these…

you're complaining so this is a good place for my complaint. coming at this from another angle, I think "the unix way" is to write your recipe so it looks like a recipe written for a human; but be careful to be rigidly precise in following a uniform format and then command line tools/scripts can parse the recipe to create an ingredients list, double the recipe, etc.

to your point, add structure/features/"coding standards" as you need for automatic processing, but otherwise you have a perfectly written recipe to whatever standards you hold.

rather than unix, what I see up and down this page is Dave Cutler slicing and dicing of data to the point of incomprehensibility. You know how you guys all loved markdown so much that you've embraced it and are now adding so many features that make it as unreadable as html? don't do that again and again, learn not to do it.

(btw I have cooked extensively and at somewhat high levels of precision (tricky sauces, souffles etc)

Re: Thinking about recipe formats more than anyone should

#132
post #128

Earlier quoted context omitted.

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

Re: Thinking about recipe formats more than anyone should

#133
Interesting... this kind of codifies what I usually have ChatGPT do with recipes I find. I have it standardise the measurements (I like a mix of weights in grams and volumes in Imperial; sue me), give me a list of utensils and containers, what order I need to have those implements in, and an estimate of time required in each phase of the recipe.

Re: Thinking about recipe formats more than anyone should

#134
Cooklang seems pretty much perfect for every use case I can think of.

I would probably prefer a more generic syntax if I were doing it from scratch, but then I'd just wind up with HTML and it wouldn't be as good for recipes.

I could see a more structured approach being useful if you were following one step at a time on a tablet, so maybe that scales better to more complicated recipes?

Most of the stuff I cook is simple enough it all fits on one screenful anyway, on the rare occasion I even use a recipe at all, so I'm not quite sure what the best approach is to cover very complex recipes.

Re: Thinking about recipe formats more than anyone should

#135
post #117

Earlier quoted context omitted.

The way ingredients and other things are described. I felt that explaining that a single word ingredient, requires @ only, but if you use multiple words, you have to use @ingredient with space{}, with the empty `{}` at the end can be too complicated to explain. I felt that for someone who is not familiar with these things, it can be confusing. In recipe-lang the explanation is IMO simpler: wrap the ingredient with `{…

Interesting, I’m nowhere near a place where I’m thinking about the implementation yet so maybe I’ll poke your version a bit!

awesome! let me know if you build something, I'd love to see more tooling around recipe-lang

Re: Thinking about recipe formats more than anyone should

#136
post #7

Earlier quoted context omitted.

That's great for writing recipes for someone to read as recipes, but it's not very useful if you're trying to create a collection of structured data from recipes.

This is one of the golden applications of LLMs. You can see the variety of structured formats proposed in comments, the different use cases, and honestly it seems like a bad idea to privilege any single format. Instead, you as a data consumer can use LLMs to parse common language recipes into the structured format most appropriate to your needs. DAG or linear? JSON or XML? You decide!

If your primary use case is displaying individual recipes that makes good sense. Less-so if you need reliable calculations at a larger scale. For example, if I was making planning software for a catering company, they’d want to know how many cases of onions they need this week for the 9 events with different menus. I don’t trust LLMs for that level of accounting yet. Hopefully soon!

Re: Thinking about recipe formats more than anyone should

#137
post #99

Earlier quoted context omitted.

I’ve been cooking with recipes quite a bit lately (before it was just random stuff) and I must say that sequencing is always wrong. Unfortunately they all seem to assume that chopping, cleaning and moving stuff around is all done in 0 time. I wish the recipes would take this into account more. Because of this I actually would prefer the plain tree organisation more.

mise in place is the art of reducing all that other stuff to as close as zero time as possible during the cooking, and many recipes expect the cook to read through first and identify what can be prepared/placed in advance. https://en.wikipedia.org/wiki/Mise_en_place

That is fine for professional recipes, when you cook for dozens of people. But for home cooking, if they say 25-35 minutes prep time 40-60 minutes cooking time, I’d expect them to count the cutting in there.

Re: Thinking about recipe formats more than anyone should

#138
post #132
post #128

Earlier quoted context omitted.

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.

Re: Thinking about recipe formats more than anyone should

#139
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 experimented a bit with that format and ChatGPT can generate pretty decent results. I described it in a blog https://cooklang.org/blog/03-ai-and-the-evolution-of-recipe-.... Here's a full graph it generated https://cooklang.org/blog/full-recipe-graph.png. I like how it was able to name intermediate nodes.

Re: Thinking about recipe formats more than anyone should

#140
post #75

Earlier quoted context omitted.

No way. The professionals I've seen use way, way simpler formats, often just simple lists of ingredients with very minimal instructions. If anything, these formats capture way too much information. For example, you can't really measure cooking times reliably unless you do sous-vide, if you want to be precise, measure temperature.

I actually agree with this. There's a ton that's between the lines in professional recipes and often much that you can't really put on paper you just have to learn at the foot of the master or try enough times you rediscover the same insights. My critique should be amended to emphasize that it's about naively constructing a model that picks and chooses elements to include based on availability, convenience, etc rathe…

Totally, we are on the same page.

First of all, you can't really model exactly what chefs do algorithmically. Or you can, maybe, but you shouldn't do that in a recipe. Unless you are building an autonomous robot-chef arm. I've seen these in China, they only cook very simple dishes.

What developers tend to forget, the recipe is a tool, and it helps chefs put together a dish. A mere combination of ingredients and maybe cooking techniques is usually sufficient for that. It is NOT an algorithm.

That's why I liked the 3 column layout linked somewhere else in this topic better than the cooking for engineers forget: it has less information which makes the things that matter stand out more.

Post reply on HN