Live data from Hacker News

Thinking about recipe formats more than anyone should

rknight.me

1–10 of 140 posts

Re: Thinking about recipe formats more than anyone should

#3

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.

Smells somewhat like the old adage of: "if the only tool you have is a hammer, all your problems start to look like nails".

Re: Thinking about recipe formats more than anyone should

#4

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

Re: Thinking about recipe formats more than anyone should

#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 Hainanese chicken recipe at https://www.google.com/amp/s/amp.theguardian.com/food/articl... ... But I find it very hard to follow in this format.

Using o1-preview to restructure it, I get something that I find much easier to follow during my cooking workflow: https://chatgpt.com/share/6733e594-df28-8009-ac80-d5dabd1ae0...

But getting from a well-written recipe to structured data is now pretty straightforward... if/when you need structure data.

Re: Thinking about recipe formats more than anyone should

#6

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.

As someone that's written a whole lot of code parsing both complex XML and JSON, I'd go with a more restrictive JSON format over a more idiomatically correct and elegant (from the data perspective) XML format any day. Complex XML sucks for storing structured data unless it's as restrictive as a JSON document, and then...

The simple use case for XML is always easy, but then it always ends up looking like this:

  prepare fruit
    prepare pear slices from a pear 
    wash
    trim
       remove stem
       peel
    
    
      slice
     
  
  ...

Plain text is great and all as a display format but it sucks even more than XML to parse as a data format.

You can make JSON that's just as stupid as XML but especially if you have people hand-writing XML, it invites a lot of complexity for a little more expressiveness. If you need to, you can always have flatter XML markup in JSON fields to avoid the large scale recursive structural insanity when parsing.

Re: Thinking about recipe formats more than anyone should

#7
post #4

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

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.

Re: Thinking about recipe formats more than anyone should

#8
cooklang is very nice but not all parsers seem willing to display comments or metadata. Eg there are two plugins for obsidian but neither seems willing to display the recipe description or anything else that isn’t a step.

You might also want to consider why you want your recipes to be machine readable. I loved the idea in theory but unless you’ve integrated this with your smart larder/fridge or something it might not be useful.

Re: Thinking about recipe formats more than anyone should

#9
Many years ago I experimented with making recipes into Gantt charts. For more complex recipes this proved incredibly useful. I spent some time trying to automate turning some of the recipe formats into Gantts, but it was pretty cumbersome. I'll bet a good LLM would make this achievable now.

For an example, here's a gantt chart for Beef Bourguignon:

https://ibb.co/c3TVTnX

Note that when I print it on a (physical) recipe card, I have the 'prose' instructions underneath.

I still think this is a pretty good idea, and I still use the cards for this recipe, and Beef Wellington.

Re: Thinking about recipe formats more than anyone should

#10

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…

Presentation and structuring is really, really important. The best I've found so far is a multicolumn format: https://i.imgur.com/w0UrJt5.png

Column 1 is the quantity. This doesn't really belong in the first column but it matches traditional ways of writing things and doesn't cause any actual trouble to do it that way, so whatever, we can do it that way. Column 2 is the ingredient. And column 3 is the cooking instructions. The rows are then grouped (shaded) by which ingredients go into which cooking instructions.

You can scan down columns 1 and 2 to get a prep / mise en place list, or just column 2 to get a shopping list (possibly involving deduplication if an ingredient is called for more than once), then execution is just running down column 3. The only real problem with execution is when it gets nonlinear (you want to overlap steps 3 and 4 in that recipe, for example) but that's a problem with any format I know of.

It's not perfect, but it works really, really well, and better than any other format I've ever seen.

...also now I want chili since it's cold and wet here in Seattle. And I should probably revise that recipe to reflect what I really do, but it's just chili, it's pretty tolerant of whatever you have lying around....

Post reply on HN