[johnorourke]

I do like this. Premature optimisation and over-eager application of DRY / SOLID are problems in software - sure, if you had 20 types of cookie all following the same recipe, abstract it. In his old codinghorror blog, Jeff Atwood suggested the rule of 3 times - the second time you do something, make a mental note, and only on the third time, generalise it.

My usual view of recipes is poor - I always see them being something like this: 1. blophicate the chicken for 5 minutes or until soft (I made up that word but you should be a good enough cook to have some idea what it means) 2. coat with a paste made from the garlic, herbs and butter (you did know you should've made that earlier, right?) 3. now add them to the fat you've been heating up for the past ten minutes (come on, surely you had that ready?) 4. serve on a bed of hand-soaked cous cous, which you prepared yesterday using this mini recipe: 4a. ...

[nefitty]

The “async-iness” of recipes had always thrown me off until I started coding more seriously. I used to think that the numbered steps represented logical sequences. Now I picture a sort of Gantt chart with multiple lanes of action sequences, which means now I have the rice and potatoes ready by the time the protein is done, instead of 10 minutes later when everything plated has already gone cold lol

[TeMPOraL]

Why not present the recipes as GANTT charts then? Even for a somewhat experienced home cook, it would be quicker to eyeball, and it would remove confusion for beginners.

I was going to say I'm just going to try this out on one of the recipes I've recently used, but someone did that already:

https://web.archive.org/web/20170420110020/http://www.matthe...

How is that not strictly superior to traditional "word-problem" recipes?

--

Also, one thing that I hate about recipes, as a person who cooks only occasionally, is the "to taste" direction. I know what to do when I've done a given dish 10 times. But the first time around? Why no recipes ever provide any kinds of bounds? "Add to taste; between 0.5 and 5 tsp, 2tsp is typical".

(Truly, cooking is what happens to process chemistry when you care so little about the quality of the outcome that you can wing every part of the process.)

[UncleMeat]

Linear text is easier to represent. Same reason why we don't lay out programs in some sort of graph structure but instead write text from top to bottom.

"To taste" is usually reserved for salt or some sort of textual element (like thinning a soup with water). Sometimes it involves pepper. Rarely will it involve other spices, though I don't think that's a terrible idea since most everybody has old ground spices so 2tsp will taste very different between kitchens.

You can't make a recipe amazingly precise for home cooks because equipment is wildly different and ingredient quality is wildly different. This is just a property of home recipes. Serious kitchens have things like salt done in precise weight ratios.

[TeMPOraL]

> Linear text is easier to represent. Same reason why we don't lay out programs in some sort of graph structure but instead write text from top to bottom.

Oh, but you actually do! You write your programs in form of trees (abstract syntax ones), and those trees generally represent directed and usually acyclic graphs of dependencies. For example:

  (defun foo (x y) (+ x y))
  (defun bar (x) (foo x x))

  (foo (42 (bar 12)))

Is a tree of tokens (with an implicit root node). It's obvious when you write in a language like Lisp; most popular languages only obscure this by a layer of syntactic sugar, but you're still writing trees.

And the reason we don't lay out programs as visual, interactive graphs[0] is because text is faster to work with using digital tools. It's faster to type the structure than click it into being[1], it's easier to grep through it, to diff it, etc. But that has nothing to do with linear flow of text - linear flow is a limitation that we do our best to work around.

--

[0] - Except we sometimes do, see: LabVIEW, UnrealEngine's Blueprints, Luna Lang, shader editors in just about every modern 3D application, ...

[1] - Though structural editors exist; see e.g. Paredit mode for Emacs, which lets you do edit operations on the tree your code represents, moving and splicing branches around while ensuring the tree structure is never damaged.

[UncleMeat]

> Oh, but you actually do! You write your programs in form of trees (abstract syntax ones), and those trees generally represent directed and usually acyclic graphs of dependencies.

Implicitly. This isn't actually represented graphically as a tree. You still have code in linear segments. You just know how to parse the text into its tree structure. The fact that code is actually parsed into an AST doesn't mean anything here. Pointing this out is just showing off. I'm happy to talk about programs as graphs (my PhD is in PL) but for the purposes of understanding how people write programs we write them as linear text.

> And the reason we don't lay out programs as visual, interactive graphs[0] is because text is faster to work with using digital tools.

Yes. And similarly, if you are publishing a recipe book the laying out text is easier than gantt charts.

> [1] - Though structural editors exist; see e.g. Paredit mode for Emacs, which lets you do edit operations on the tree your code represents, moving and splicing branches around while ensuring the tree structure is never damaged.

Yes we all know. There's been decades of research in this space. And basically nobody in real life uses them.

[globular-toast]

I think about like a dependency graph. I am make and the recipe is the Makefile.

When I was learning to cook my process was to read the recipe thoroughly, including any instruction on techniques. A good book will tell you how to chop an onion and sauté it. I would then distil this into a dependency graph which I would write down in a book. I still have this book. A recipe in there looks something like this (excuse the bad ASCII art):

    2 eggs      -|
    200g sugar  -|---- beat together---|
    200g butter -|                     |
                                       |--- combine --- bake
    240g flour      -|                 |
    1tsp baking pdr -|-- combine ------|
    1tsp vanilla    -|

Notice that, just like make, I don't need to write down how to beat or combine stuff together. I have a library of known steps to get from those ingredients to the desired state.

Nowadays I don't have to actually write this down because I stick to a few cuisines that I know well (English, French, Italian and Indian generally). I know 90% of the techniques I'll need for any recipe so I can simply read the recipe, assimilate it, then execute it in the kitchen.

The two biggest mistake I see new cooks making is not reading a recipe through first, and not building a library of common techniques. Instead I see people taking the original recipe right into the kitchen, often on their phone these days, and executing it as they are reading it through for the first time. This usually leads to incredible amount of wasted time due to poor scheduling. Always aim to be free of the recipe. Like a musician you should eventually be able to play the piece without the music.

[tincholio]

There's a website called Cooking for Engineers that takes a very similar approach. http://www.cookingforengineers.com/

[roel_v]

cookingforengineers.com has developed a formalism for such Gantt-like charts for recipes, that show visually the dependency graph and critical path of preparations.

[TeMPOraL]

Oh, those guys are still around? Thank god. And thanks for bringing it up. I remember reading their articles ~9 years ago, I'll need to revisit. That was about the only cooking-related site I felt speaks comprehensible language.