No! Handle units! @milk{4%cup} should be trivially convertible to liters and configured by the user. For harder conversions (volume to mass) keeping a list of ingredients and their densities (configurable of course) would be extremely useful.
On that subject, being able to specify a recipe in terms of ratios and then automatically convert it to scale would be a super power that I can't beat by hand.
For example when I bake I do everything by weight and have all the recipes I like written out by hand with unit conversions. Because measuring by volume isn't easier in 2023 than placing your mixing bowl on a kitchen scale and balancing everything to the mass of your butter and eggs.
No! That's silly and it's not how cooking works! This way you get stupid recipes like on American cooking Youtube channels that just run their volumetric measurements through a converter and end up with recipes that call for 234 grams of flour, 13.5 grams of this or that spice and 78 ml of whatever. Recipes are (well, should be) tuned to the measurement system they use, and packaging availability in the area it targets, so that you get recipes that use e.g. 400ml of coconut milk (because that's the most common can size around here), whole numbers in amounts of ingredients etc. Converting between units in cooking and baking is not simply using a unit conversion calculator on your phone!
(and that's not even mentioning that there are UK, Australian and US cups, tablespoons and teaspoons)
Actually the USDA maintains this information in the FoodCentral database. I built a recipe management website using this information, for example check out this page: https://letscooktime.com/Recipes/Details?id=09989dc1-ee98-4f...
I think Cooklang is neat but non-developers are never going to learn it to write recipes. CookTime (my website) allows you to write structured recipes using a GUI, and soon you'll be able to use AI to just enter in random text and images and import them as recipes.
Nope, apparently it's just water/flour...which doesn't make sense to me, as it allows 'hydration' to go over 100%.
Eh, I've tried both and I have to disagree. Pouring milk or oil may be easier with the scale because you have very precise control over the flow rate, but for flour and other dry goods it's far easier to scoop, scrape, and dump a cup than it is to add a bit at a time while avoiding the sudden avalanches that inevitably start as things loosen up.
However dry goods like flour are hard because so many little things affect the density of the scoop. Vs if I just put it on the scale and scoop it into a bowl/cup on a tared scale, I can get it most of the way there and then just spoon in/out little bits to get to the right mass.
For cooking I find it doesn't really matter but with baking where those ratios are so strict, mass measurements for dry goods is just so much more repeatable.
For liquids you don't have precise control over the flow rate so it isn't easier to do over the scale. Although depending on the circumstances it is because you don't have to worry about spillage.
My mom taught me when I was a wee lad that a heaping table spoon was about 20g of flour, and a flat table spoon of sugar is about 10g. I have no idea if this is true, but to get 200g you get approximately ten table spoons, and you just get a bit less or more in the late one.
Somebody mentioned here a couple of weeks ago that you can use a slide rule to do scale ratios in a recipe. I can't find that link now but here's a build-your-own recipe converter (circular) slide rule that I found:
https://www.reddit.com/r/Cooking/comments/v7ilgv/cooked_up_a...
If this thing was paired with a mass scale at 1g accuracy with a dynamic range of like 0 to 5kg, I would pay like $50 for this.
To use cooklang, it appears that I have to rewrite recipes to include ingredients inline. No other recipes tend to use this style, because it is harder to read.
If I write recipes in cooklang, the plain text of the recipes is harder to understand without tools that speak cooklang, forcing me to use the tools to get an understandable format. The output of the CLI tool seems like a better format than the format itself!
I don't understand. Recipes absolutely include ingredients inline, because unless your recipe is a single ingredient you would need to mention the name of the ingredients that step uses. The option to include measurements with the ingredient is also important for recipes that use the same ingredient in different steps.
The fact that it generates the ingredient list from the instructions is a positive, because you only need to modify the recipe in a single location rather than multiple locations. Those old 1890s cookbooks you mention often have typos in either the ingredient list or instructions because of this.
> If I write recipes in cooklang, the plain text of the recipes is harder to understand without tools that speak cooklang, forcing me to use the tools to get an understandable format. The output of the CLI tool seems like a better format than the format itself!
But that's exactly the purpose of markup language. Nobody is saying XML is easier to read than a table generated from XML. Neither is HTML, LaTeX, or any others. The only exception to this rule I can think of is Markdown, which is at best equally readable in both plaintext and rendered formats.
The output of the CLI tool is suppose to be a better reading format.
Sure some recipes require the same ingredient in different steps. Why optimize for an edge case and making the default case harder? It's solved "take half the butter..." and "with 100g of the sugar... Pour the rest of the sugar..." works well for the 2% of recipes you need this in.
The original vision for angle-bracket markup (SGML) includes support for custom Wiki syntaxes (SGML SHORTREF), tag inference, and other affordances for compact, hand-writable text. In fact, SGML can be seen as a language to specify cues for turning markdown-like text with arbitrary custom extensions into strict fully tagged hierarchical XML.
See for example https://www.cookingforengineers.com/recipe/36/Meat-Lasagna
This was my initial thought too - ChatGtp to the rescue: https://sharegpt.com/c/ivxamU9
I think this would be really cool to store the recipes one has tried and likes locally.
As much as I like the convenience, it's a double edged sword - we are removing the incentive of recipe authors to share.
The recipe credit: https://www.isabeleats.com/mexican-slow-cooker-pork-carnitas...
And personally I'd prefer to see quantities next to where they're being used, rather than just "the milk" or whatver.
Then finally you reach the footer and click on https://github.com/cooklang, then you see it has a bunch of cooklang libraries, e.g., TypeScript, python, C, etc.!
It even has a VSCode syntax highlighting package!
I appreciate the comprehensiveness of the project. It’s more than a markup language, cooklang seems to be an entire ecosystem.
I shall poke around the cli code.
I could add metadata tags that would indicate just what the dish was (entree, or a fancy breakfast/brunch, or a desert, etc), but since there's nothing like a standard tag if anyone else gets the file those tags are mostly worthless (their software won't be able to sort a bunch of recipes into the correct categories).
There's no way to indicate how many times the recipe has been verified (apparently the vast majority of online recipes are made-up bullshit that even the author hasn't bothered to cook even once).
Even pictures... I might want more than one non-step picture for the recipe.
Naming convention is whacked out. This works for 5 recipe files in a folder. What happens when I have 80,000? Or 2.1 million? r/datahoarder would be disappointed. How many different pot roast recipes is that? Is it only eight dozen, or is it more like 900? Are they all just numbered, 1 through n?
Hell, there are some classic recipes that are seasonal. They want not just "chicken eggs" but "spring chicken eggs" as opposed to summer or fall. How do I filter those out so I don't see them in November?
However, if you want to make shopping list annotations, then you're doing that extra work anyway. In a separate file? It'd be cool if the spec allowed for doing an ingredients list with annotations at the top of the recipe if the writer so chooses. The current syntax works, but not for all people/scenarios.
How would I do recipes with sections? For instance: https://www.kingarthurbaking.com/recipes/fast-summer-berry-p...
Note the ingredient sections; crust, filling, topping. Note the step numbers. Note the link to another recipe. Note the step section titles that are represented here in bold and which don't perfectly match with the ingredient sections. Note the footnotes at the end.
Not sure how I'd do most of those things with this markdown spec.
The benefits are that you get distinct ingredient lists for each component but they get aggregated when you create a grocery list.
Check out the discussion from last year here: https://news.ycombinator.com/item?id=31201528
So, are the components different files? That'd definitely help if there's a component that applies to several recipes, like a sauce or crust. However, it could make things more complicated than some would like if they're working on a smaller project, like a reference notebook or a family cookbook.
Power vs simplicity is often a balancing act.
The idea would be a recipe generator the uses taste profiles, food textures, but has no standard ingredients. If one only had taro root for flour all recipes would sub that in...
Why?
Sure, since it's markup you could sum them to two eggs in an auto generated ingredient list, but for a general text format recipe, I'd like to see the egg in 3 places. In the ingredient list it must show "2 eggs" and then on two different locations in the recipe it will say "add 1 egg".
So, I think the primary disconnect I had was that I thought this was a spec for a recipe, but it's actually a spec for a component of a recipe, or an entire recipe that only has one component. The CookTime person replied to me and showed how the spec can be used in a component paradigm, which makes it much more usable.
[0] - www.reciped.io
The search is spartan at best and I could not find a list of all the recipes.
Hamburger menu leads to a links page which is empty.
I quickly gave up.
It's definitely something I'm still working on, but has been very usable.
EDIT: It has an obsidian plugin, though the last release was 2 years ago: https://github.com/deathau/cooklang-obsidian
I'd probably find myself less motivated to simply type something out to recipe.txt vs. manage all this but CookCLI does open up some interesting possibilities.
The first thing that came to mind would be that it'd be cool if CookCLI could "halve" recipes automatically. Say you had a recipe for 12 muffins but you only wanted to make 6 or 4, it could automatically divide those quantities and spit out a new recipe or shopping list.
Another cool CLI feature would be unit conversion; converting things like fluid ounces, or cups into ml.
My other piece of feedback is the overloading of {} for ending multi-word ingredient seems a bit off. It's more syntax but I'd still rather have something dedicated for that purpose eg. @(ground black pepper)
The problem is that scaling recipes doesn't work this way, particularly for baking. Some ingredients don't scale linearly, cooking and mixing time doesn't scale linearly, etc. Savory items also have scaling issues, for example, some dishes include extra liquid that is lost to evaporation while cooking; you would likely not want to scale that up and would end up too much liquid at the end if you did. The opposite can be a problem too, don't scale down liquids in pressure cookers without thinking because you might end up without enough.
You would need a lot of extra metadata to be able to effectively scale recipes.
A recipe for 6 baked potatoes could probably be halved linearly, a recipe for pancakes could also probably be halved as well.
Yep, or just use the same tag marker at the end of the multi-word thing: #pot, #pressure cooker#, @onions, @ground black pepper@.
>> servings: 2|4|8
Add @milk{1/2*%cup} and mix until smooth. -- Multiply by serving size
Add @milk{1|2|3%cup} and mix until smooth. -- Specific quantity per serving size
https://recipemd.org/specification.html https://recipemd.org/cli.html
Some years ago, I came across a recepie as flowchart graph. This idea appealed to me instantaneously, because a picture to me is a thousand times better than a lettersoup. Especially when I'm not constantly reading the text, but have to check the pots and pans regularly.
I think this markup language could be used as input for an engine that generates nice recepie graphs.
And then an integration into the tandori.dev application?
I write them in markdown and use fossil's webserver to be able to access them while in the kitchen. If I need to see ingridents while i'm out, i activate my tailscale VPN on my phone and browse to the fossil webserver.
Thankfully i'm not the only one who has oven-engineered a simple solution.
I wrote them with pen and paper. Recently I experimented with the mermaid extension for markdown. It has its drawbacks but works.
https://buttondown.email/hillelwayne/archive/edge-case-poiso...
It's pretty funny watching every conversation about food or cooking on HN turn into confident assertions of how it should be done. Meanwhile every attempt to do it smashes right into these problems and, while maybe gratifying for engineers, are virtually worthless to cooks. You can tell by the fact that no cooks use these systems.
This is walking the line of laziness (why don't I just look them up myself), but it sounds great.
Maybe I can combine the web server with a customized GNU units.
I don't love the % either.
Fun stuff, nice creation!
There's something quite simple and elegant about them.
Show HN: CookLang – Recipe Markup Language - https://news.ycombinator.com/item?id=28997309 - Oct 2021 (146 comments)
For instance, why is the % required? There aren't that many units; surely {0.5 kg} can automatically be parsed, rather than requiring {0.5%kg}.
Or do you think the software should only support English?
A Vietnamese recipe will often use "gr" for grams (even though SI says that's not correct but what are you going to do?). A Japanese recipe will say something like "1/2パック". And so on.
Any time a recipe says something like "a dash", "a pinch", "a handful", "half can", "a dollop", "a generous pour", "to taste", or "extra large eggs" -- all things that are extremely in real world recipes -- it will be written in the local language.
I don't think the markup language intends every single measurement to be converted into laboratory measures using only official abbreviations, which feels unnecessarily restrictive.
Show me all the recipes that use the oven, sous vide, grill, smoker, etc.
