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)
My point is - recipes cannot be converted easily between unit systems. There is more to converting a recipe than applying a ratio table.
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.
I think any recipe for roasted vegetables has to be by volume of the chop/dice fwiw. There's lots of ways to chop carrots into 20g chunks, but they won't all cook well or evenly, so a 1/4" dice is what you'd call for (even if you call for 600g of carrots)
(I guess this would also apply to baking anyway.)
Nope, apparently it's just water/flour...which doesn't make sense to me, as it allows 'hydration' to go over 100%.
Really it's _just_ the ratio, normalized to 100 for convenience
Making a 80% hydration pizza dough? Just measure how much flour you added and multiply by 0.8!
You're going to be much closer following mass measurements than volume ones - your flour may have different moisture and protein levels than the author's. But those are minor compared to the >25% variations in flour when measured by volume.
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.
This is as un-winnable a debate as vi vs emacs.
The world is full of both kinds of people. Any attempt on the part of the format to dictate one or the other approach will simply reduce the use of the format. As firmly convinced as you are of the rightness of your position, there is at least an equal number of equally committed champions of the other position, regardless of which position you hold.
Encouraging/facilitating the presentation software to accept data in either format and render it in either format will be the winning solution.
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.
I understand that part. What I'm questioning is how does including an ingredient list also eliminate the need to include the ingredients inline? I don't even know how you'd make a recipe that doesn't say the ingredient names inline.
> Yes the tools can generate the list but you need the tools.
That's kind of the entire point of markup languages though. You define a clear schema that a tool can process to generate a clean or convenient document out of. This is true for pretty much any markup language. If that's an issue for some reason then you can just use plaintext.
> 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.
Begging the question of whether this is actually an edge case. I'd argue it's not. This case covers a huge number of the recipes I use, including simple ones like bread recipes.
I'd also argue that this makes the "default case" easier, as you only need to focus on writing the actual steps involved. You're not going to get any typos or mismatches between your ingredient list and the instructions. That's especially a benefit if you're editing those recipes down the line, which is what I presume the typos in my older cookbooks have.
An argument could be made that it makes reading the markup annoying, but I need to reiterate that markup is primarily for writing.
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.
At the moment, Umami's scraping is done server-side. I'd really like to speed it up, so I'm going to start working on a 100% client scraper soon (for the native apps & browser extensions; the web version will always have cross-domain browser restrictions though).
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.
Thanks for making an account! You can only edit you own recipes, but I (the admin) can edit any recipe. I guess you tried to edit a recipe you liked, would you like a "Copy and Edit Recipe" feature?
> So, are the components different files?
Components are what CookTime recipes are made of. A recipe has at least one component, and if necessary the author can add additional components to indicate different ingredient quantities for different components. I have thought about having re-usable components across recipes, I just haven't given thought to how to design the UX for it. Glad to hear that someone else would find it useful, I think I'll reprioritize this.
> I can't figure out how to look at the markdown.
In CookTime there isn't a simple textual representation of a recipe (unless you count the big JSON object the browser sends over the wire.). The backend is a relational database of recipes, components, ingredient requirements, nutrition data, etc...
> Power vs simplicity is often a balancing act.
100%, my primary user is my mother-in-law and I have to be extra careful to make everything easy to use for an enthusiastic retiree.
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...
Can you tell me more about what you're looking for? CookTime's recipe object modeling is very flexible, maybe I can make what you're looking for in a generic way.
[1] - https://researcher.watson.ibm.com/researcher/view_group.php?...
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.
My bad. Yes there's the register and login links. I guess I was taken off guard by the hamburger menu redirecting to https://www.reciped.io/links/ and showing the links there.
> A list of recipes would be completely overwhelming
Well it would be a good way to see how many recipes there are.
https://www.reciped.io/search/?search=flour currently lists 4 recipes and 2 ingredients. That, is not very many recipes requiring flour?
https://www.reciped.io/search/?search=egg lists 3 recipes.
https://www.reciped.io/search/?search=salt shows 12 recipes, leading me to think you have... hmm... maybe about 20 recipes total? Not my idea of overwhelming.
---
I mean, I could register, sure. But it's not even clear to me why I'd want to:
- If I want to find interesting new recipes, I don't have to register.
- If I want to keep track of my recipes, so that I can make it them the same way the next time, I don't want to register and record my recipes on your website, because now anyone can alter them.
---
I like the website overall! It's minimalistic, no bloat. And I like how you include the nutrition information!
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.
