Is anyone working on let's name it CookHub already? So essentially GitHub for receipts. The nerd in me wants to fork receipts and share my small adaptations to the community.
That would be pretty cool. It would already work in github, but yeah a dedicated site would probably be better ;-). I'm afraid that the intersection of people interesting in cooking and people who know how source control works is likely pretty niche
The other problem I have with community cooking websites is that usually people always underestimate the cooking time and that's annoying as hell. Like people would say you need to cook onions for 10 minutes, while onions take close to 25 minutes to be cooked. On the French website marmiton, it was so ubiquitous that they have moderators come in and fix people's recipes.
My issue with recipe timings is that even if you cook things for as long as it says, the overall time to cook the recipe is always very "optimistic". I assume the issue is some combination of marketing and the fact that the test cook was done by a professional chef who can dice 10 onions in a minute.
Ingredient prep is intentionally left out of recipe timings. In theory, this lets everybody adapt the recipe timing to themselves, because only you know if you can chop two onions in three minutes or thirty seconds, but as with the Doomsday Device in Doctor Strangelove, it's worse than useless if nobody knows about it. "Why didn't you tell the world?"
I imagine it’s done that way because people don’t necessarily know what to look for when cooking something. If some one doesn’t know how to cook steak, you can’t tell them “cook till medium rare”. So we start trying to come up with proxies.
The main problem for me (who am interested in cooking, as well as somewhat au fait with version control) is that at this point in my life, I could not for the life of me write down a recipe for almost anything that I cook, because it is all based on "enough" and "to taste", with cooking times being in the "well, you look at the ingredients and a cooking schedule effortlessly forms in your mind" (none, by the way, based on actual time), allowing me to do things like cooking things in the oven and three or four pots on the stove, and have everything ready at the same time, by staggering the start times.
And I literally cannot tell you how I do it, because at this point, I don't know. I do know how I got there, though. Cooking, lots of it, at various scales and in variously equipped kitchens.
Scale-wise, I have cooked for 1. And on the upper end, I have cooked for about 50.
Fantastic idea! Another benefit I can think of having such a repository combined with this markup language is powerful semantic searches - filtering by sets of ingredients, and perhaps adding the ability to add tags to the recipes
Yeah, the same here :-). We created a placeholder repo https://github.com/cooklang/recipes, but it still subject to workout structure and probably it makes sense to standardise units in some way.
I’m not sure you’d want to fork it like version control does. If someone makes a variation that is not a correction, you’d want to have that easily available on the main repo with a link back to the original.
https://www.cinc.kitchen/info/features lets you fork recipes. forkthekitchen.com (now dead) was another similar effort. So did diy.soylent.com (now dead as well).
hRecipe looks like it's just HTML/entirely web-based, and Schema seems like it covers way more than it reasonably should.
I personally think CookLang is the better of these, even this early on.
hRecipe is over 10 years old, and the point of microformats is to extract semantic data from HTML. It's not really solving the same problem as CookLang in the way HTML and JSON aren't solving the same thing.
While I don't know much about the history of Recipe in Schema, I find "covers way more than it reasonably should" to be an odd criticism of a format. I usually find it to be a mark of schema maturity. All concepts behind data formats have more complexity than an initial investigation would uncover (see also: Falsehoods Programmers Believe About Names[1]). If anything, it leads me to believe CookLang has a ways to go.
I've been working on a stove safety/smart cooking device which is based on the temperature of your pan [0]. There are a small number of recipes which it currently works with [1]. To do this we defined a JSON format for recipes [2] but if we could use something similar to the text format used by CookLang that would be amazing, as it's much easier to write than JSON and could also be automatically rendered into a web page. Currently we are writing it twice - once in JSON for the cooking app, and once in human readable form.
The newsletter pop-up made your site unusable on mobile. Hard to close, and then it kept coming back. Obnoxious and rage inducing. I hate your product now.
I'd be interested if there's research showing whether a one-off popup gives more signups or more annoyance. The marketing people seem to think it's better to have it there.
I agree it's hard to close, I'll see if I can do something about that. It shouldn't keep coming back once closed, which browser are you using? Although it does come back if you refresh the page. I might be able to do something about that as well.
I just noticed that this kind of pop-up appearing is a trigger for me to close the page. I immediately get the feeling that I got the basic idea of that page.
Personally, those popups are an immediate close tab for me. If you have no confidence in my wanting to sign up for your news letter after I've seen your content, I don't want to bother with your content at all.
You should ask your marketing people to back up their beliefs with research. While you are waiting think about how you react on other sites that use pop-ups. For me it’s an insta-close. YMMV.
I'd be interested in a paired device to interrupt the energy source to the stove. If danger is imminent and the operator hasn't responded in a certain timeframe, a connected valve would turn the gas supply off or a switch would trigger the electricity to turn off.
Growing up we had a sensor in the oven go out, causing the cookies to catch on fire inside the oven. We also had a control board on a Whirlpool dishwasher start smoking ~15 years ago. There was a class action lawsuit against Whirlpool, but we didn't have any documentation that showed the model and serial number of the unit, so we couldn't get the typical "$20 credit for your next appliance purchase" or whatever the compensation was.
In both cases, flipping the electricity off at the breaker prevented further damage.
Thanks for the suggestion! We did consider the idea of making it automatically cut the energy source. However at the moment, the install steps are: receive it in the post, pull out the battery tab, and stick it on your stove splashback with a strong sticky pad. Almost anybody can do it themselves. As soon as you need to cut the electricity/gas it requires a qualified engineer to go in and install it, making the install cost an order of magnitude larger. So this wouldn't be a part of the core product.
As an optional paired peripheral, it's a good idea, and perhaps we will look into it further if the main product has some success. If individuals consider it a valuable addition then they could pay to have it installed. A secondary drawback would be reduced battery life on the device, as it would be continuously paired over Bluetooth whenever the stove is in use - usually it is just passively advertising in case you are trying to connect through the phone app.
In terms of saving lives, the automatic cut-off would make a relatively small difference - fire department stats (on smoke alarms) show that having a loud beeping alarm is extremely effective at attracting attention and is enough for the user to go and turn it off manually, or to get out of harm's way if things have turned bad. Where the automatic cut-off would help is in reducing the chance of the house being damaged by smoke or fire when the user is out of range.
Actually, if one defined an XML or SGML DTD, you could inter-weave text and mark up seamlessly without having to create yet another markup language; another reason to standardize is not having to write readers/writers/converters again and again.
I'm curious - have you tested with oils with various smoke points? How does your device know which smoke point to monitor for? That's a 300F range (225 for Sunflower oil - which nobody should cook with, but if you want to prevent fires, look for the people doing things they shouldn't do, but that are convenient. 300F for butter, 520F for avocado oil)
Also, since I have a thing for flambee dishes - how does it deal with pyromanic chefs? ;)
It doesn't know which smoke point to monitor for. However, the aim (at least for the MVP) is for it to work the majority of the time for the majority of users - and critically to alert several minutes before there is any flame. So while sunflower oil may start smoking a small amount, it would be several minutes more getting to flame, by which time the alarm should have sounded.
If you put a frying pan on with oil in and leave it, the device will alert you at around 450F. This is a fixed threshold (along with some other checks, e.g. we also consider the rate of change of temperature). This gives reasonable behaviour in most cases, and ensures you don't get nuisance alarms when frying on high heat. In cases where individuals have an unusual cooking pattern which causes unreasonable false alarms we can adjust the model parameters to increase/decrease sensitivity in particular situations. In the future we may be able to adjust these automatically but for now there is not a great deal of automated "learning" involved.
If you're a pyromaniac chef, I think you would get some alarms from that! Again this is a bit of an edge case so we haven't but much effort into that for the first iteration of the product, definitely something for the future though - I can imagine it being a challenge to distinguish flambee and a real fire though, since flambee is real fire!
I was actually thinking about my wishlist for recipe apps the other day. Some key features:
1. Split up ingredients into more parts.
2 tbsp ground black pepper is actually:
Quantity: 2 tbsp
Ingredient: Black Pepper
Preparation: Ground
2 finely chopped scallions, just the white parts
Quantity: 2
Ingredient: Scallions
Preparation: Finely Chopped
Note: Just the white parts
Often you'll have apps (like plan to eat) that adds the preparation to the ingredient and makes shopping lists much harder to manage
2. Ingredient replacements. Often you'll see recipes calling for one ingredient and then has "You can replace this with x and y". It would be extremely nice to have this programmatically available. I know if I can't find scallions, I can replace it with garlic and onions.
3. Variants. Often I have the same core recipe in my recipe book with just different variants. Meringue cookies with different flavors. 90% of the recipe is all the same, but it's duplicated a dozen times for a dozen specific flavor add-ins. It would be extremely nice to have this somehow programatically available, so I can have the base recipe and all the variants with a reused core :)
I wrote a service called Zestful that does exactly this.[0]
It's an interesting problem. It's hard to train an ML system on the distinction between a preparation instruction like "finely chopped" and a note like, "just the white parts." My system treats "just the white parts" as a preparation instruction, but it throws away as irrelevant things like, "My favorite brand of black pepper is Smith's Fine Peppers." But I've looked at thousands of ingredients, and there are lots of wacky edge cases.
I created the service by adapting an open source project the NY Times published and then abandoned.[1] They were trying to index all of their old recipes for what would eventually become cooking.nytimes.com. Their repo felt very experimental and half-baked, so it was interesting to turn it into a production service. I wrote about the process of creating the service on my blog.[2]
Agreed - I've always wished recipes would have two ingredients lists: one for shopping and one for prep. Like some recipes will call for half a cup of diced onions... So do I buy one onion or two? And recipes that spread ingredient prep throughout the steps make it a pain if you want to prep up front. Having a semantic list of ingredients means you could display them in whichever format is more helpful in the moment.
My other gripe is when recipes tell you to prep 4 tbsp of an ingredient but aren't clear that you only use 3 in an early step and are supposed to save the other 1 tbsp for an end step. Not sure how this could be programmatically solved though
The amounts could just be tied to the steps. So maybe step 2 is to add 3 tbsp of ingredientX, and step 5 is to add 1 tbsp of ingredientX. So programmatically, the ingredients list would be the cumulative amounts of all ingredients described in each step, which would be 4 tbsp ingredientX.
Now that I've tried it, that seems to be exactly how CookLang does it. Though it would be nice if there was a sort of asterisk or note in the ingredients list that indicated the quantity is split between steps
... Or you know I could just learn to read the instructions carefully and not dump the whole bowl of garlic in at once. That'd help too.
2 and 3 certainly useful features and some day we'll have it in Cooklang.
As for 1. I had this before in spec:
> To modify the ingredient any other way, use parentheses.
> Add @onions{3}(finely chopped) to the mix...
After some testing, it turned out that it makes the overall cooking flow a bit convoluted. This modifier is an implicit step of the recipe. Imagine that we have this modified ingredient in the middle of a recipe. I have my frying pan full of things and next step is to add onions. But I suddenly realised that it's time to finely chop onions and I don't have time for that.
We can create these steps automatically and place them before everything else, but it may not be always the optimal way.
Note: this will significantly reduce the life of your oven. The self-cleaning cycle is torture for the oven components. They are not really built to withstand the heat.
Just out of curiosity, is there any interop that you'd personally benefit from? I'm unfamiliar with schema.org's more ephemeral schemas and how commonly they are used.
What's the markup for "unrelated long-winded story because I wanted to be a writer"? :) Great idea, and I agree with another commenter that a github-style recipe sharing/forking system would be a good addition.
The intro serves a couple purposes. It ensured the text of the recipe was "below the jump" on RSS readers, so the audience had to go to the original sites (and see ads). It helps detect and trap plagiarists - it's copywritable, while a recipe isn't. But it also contextualizes the recipe. It's really important for me to understand if I'm seeing an easy weeknight favorite or a labor-of-love Sunday meal.
Beyond just looking at the timing, I want to know how a cook thinks about the dish. If you open cookbooks, the intro spiel is common, and I often find it more helpful than the actual text of the recipe. There's a million places I can read a recipe for pad Thai, but Andy Ricker and Leela Punyaratabandhu have some deep insight that is very valuable.
Certainly some authors are crappy writers and don't add value here - I don't follow those people. Googling for recipes will turn those people up too often.
I heard that the long-winded stories also serve to make the text longer for SEO purposes. i could imagine that it makes you stay longer on the page, because you look for the recipe. Also, more text equals more opportunities to insert ads.
This is an unnecessarily harsh characterization. Recipe writers are constrained by economics, just like the rest of us. It's dismaying to see such cruel mockery on an industry forum. You may also want to look into Fundamental Attribution Error: recipe writers are "flawed", in your mind, but do you judge yourself so harshly? Likely, not. You probably excuse your own misbehavior as compelled by transient circumstance.
This looks awesome!
I wonder how difficult it would be to integrate it with Gnome Recipes?[0]
The interface is really nice and even automatically makes shopping lists for you based on recipes and intended servings you selected.
This is interesting. A year or two ago I tried creating my own web application [1] for cataloguing recipes. It involved creating a parser in Elm [2] that could handle JSON generated by org mode files (where I stored the recipes). It was far too convoluted - but it gave me some of the features that I wanted - simple pages with recipes, with hover-to-see-quantities, as well as a cooking timer. If I was to do it again, I might investigate using something like cooklang to see if I can get the same functionality out of it.
Nice! I wasn’t aware of that project. It has very similar idea. In cookcli there's a small web server too. It’s not fancy or very developed, but allows to check the recipe or manage shopping list
Every recipe (and recipe language) must include links to descriptions of ingredients and/or alternatives.
I have no idea what a "medium victorian spring spruce potato is" or whatever it is you're using. In Sweden we have only two kinds: hard and soft. Same goes for basically everything else :)
In north Sweden we have also only two kinds of potatoes. One is called Mandelpotatis, and then we have all the rest that noone buys.
Seriously, if you don't like potatoes or think it's boring, try Mandelpotatis (if you can find it, it likes sandy, not very nutrious earth to grow or it will get sick and die :-)
I have been thinking of a way of writing my recepies so I can process them into a database some day for easier search. I realised I would never have the energy to actually do it so I'm just switching to markdown and running a static webcompiler on them to output html with search function in javascript and upload to github. Works better than expected and have everything I need.
Sounds like you have a similar setup to mine [1]. I have added PDF as an output format using pandoc. Also GitHub actions to automatically generate a new version when I push a commit.
Would you mind sharing yours? I am always looking for inspiration and ways to improve.
From the potatoes that are immediately visible on display. You have large stands with two types of potatoes that you can pick and weigh yourself (sometimes three, the difference isn't obvious). Then you have a bunch of 3kg-5kg packs of washed potatoes of two kinds: fast and mjölig.
And possibly there are one or two packs of other kinds? Maybe those 3-5 kilo packs have different types of potatoes in them? But those are never clearly marked.
And then you arrive at a recipe, and it calls for russet potatoes or dutch cream potatoes or some other potato. What the hell are those? :)
Anyway, potatoes were just to illustrate the idea. I've had the same issues with rice, vegetables, even spices sometimes.
A way to do this would be to start with a list of ingredients/techniques, and have a "dependency checker" that checks that every ingredient/technique is either in the list, or explained elsewhere. This way, the base would be explicit, and you can easily track explanations.
That was the motivation. I had the same problem that recipes from the apps aren’t localised to local produce. Also sometimes I want to cut corners and do thing easier. I should be able to apply agile and maintain my recipes in my way :-)
Hard/soft presumably corresponds to the waxy/floury categorization Anglo countries often use. It shouldn't be hard to find which category a given variety of potato better fits into.
This reminds me of RDF recipe ontologies (as they can be used with RDFa: e.g., schema.org's Recipe[1] and the food ontology[2], and there are/were dedicated spiders to search those, such as openrecipes[3]), but with a custom syntax; might be nice to define mappings to/from those, for compatibility. Though unfortunately the larger open recipe databases I saw online tend to use custom (sometimes XML-based, at least) formats/structures, so there's nothing quite readily usable (that I'm aware of) as a result.
I've been looking for a way to index my mother's recipes in a useful way, was somewhat motivated two years ago.
I wanted something that:
1. produced well formatted PDFs for printing (my mother prefers paper).
2. it would substitute different ingredients. i.e. this recipe contains milk, a simple button or keybind would change it to an appropriate milk substitute.
3. automatically produced different measurements.
I tried GNOME Recipes [1] as it checked a lot of boxes but it has some big bugs still that make it basically unusable.
I considered maybe doing something org-mode and emacs, but kind of lost interest after that...
Like the ability to double measurements. In the emacs example you'd be able to hit a key bind, enter how much to divide or multiply the recipe and it would automatically change it.
I've tried a number of recipe apps, etc. and I got to tell you, most are just work. The worst are the ones that make you use a GUI with dropdowns for things like teaspoons or tablespoons.
I use a wiki. I can cut and paste a recipe into it. I don't even really care much about markup; I can read it just fine. I can access them from laptop, iPad, etc just fine and I don't have to have the software installed on everything.
[0] I know this isn't an app, it's markup, and like I said, looks really cool. Just seems like it would be more work than just using a wiki.
A question. How do I connect images to recipes. I usually have multiple for single recipe. It would be nice to have some keyword for that and/or configured location...
On iOS app there is a picture for example, how is it represented in the .cook file ? I see Adding Pictures section but it says it should live in the same directory ? Any option to specify that differently as in your seed all files will be in the single folder and there will be mess on file system. I would for instance prefer to have a folder per recipe with cook file and images.
Yeah, we can only set one title picture for a recipe. Noted down your question.
> Any option to specify that differently as in your seed all files will be in the single folder and there will be mess on file system. I would for instance prefer to have a folder per recipe with cook file and images.
That's a valid point, We assume that people only occasionally add images, but I can imagine its becoming messy. Maybe we should add alternative way. Noted this down as well.
This is nerdy and probably superfluous but I actually love it! The .cook extension is such a cute touch. I actually do already store all of my recipes in .txt files, so maybe I'll convert them to this and create some shortcut scripts for quickly search my recipes while I'm at it :)
I agree, I thought about that. I expect that it can be some cases when either ingredients or units have spaces. And the problem is that I can't come up with a solid counter example. Something like @coriander{2%small batches}... You can open an issue in a spec repo so people can discuss https://github.com/cooklang/spec.
Having an explicit delimiter allows for whitespace in either amount or unit. I suppose that's the reason. Can't seem to come up with an example for that on the fly though.
When reading a recipe I always end up mentally translating the prose / steps into a DAG, but I don't have enough short term memory to keep the DAG in my head so I'm constantly re-compiling as I'm working.
When I write my own recipes (on index cards or whatever), I explicitly create the graph to make it easier to follow. Of all the links in this thread, the "Computerized Cooking" one most closely models my ideal setup, but I don't love the RxOL language. Maybe I'll make an s-exp version of it that exports diagrams someday.
I like it, a lot. However, the syntax for linking steps to pictures should be rethought, IMO, what if an image already has numbers in its filename? Could get confusing very quickly.
Agree, this was a last-minute hack. If you have an idea how to rethink this you can share one in a spec repo issues if you don't mind https://github.com/cooklang/spec. Thanks!
One thing that doesn't look possible from the spec is supporting recipes with multiple discrete parts. An immediate example for me would be I made a fish dish that had an optional salsa to put on top. I substituted the salsa for something else, so given a recipe, it would be nice to see "here are ingredients for the fish, here are the ingredients for salsa", and that they don't go into a unified singular count of ingredients.
Yesterday a friend remarked to me she had lost a recipe for something or other and I resolved to start recording some I use, I was thinking of something like MD/Obsidian but this looks really good.
Great to have the iOS app, an easily convertable human readable and writable format and hang on to your own data.
Going to give this a good look over today. Might think about an Obsidian plugin as well.
interesting language, didn't have the time to read the details/spec but, what i found most difficult when reading recipes on the internet that the ingredient names change dramatically between countries(event with the same spoken language), does this language attempt tackle that problem? also it would be nice to have alternatives for some ingredients.
Agreed, recipes often need localisation. The language itself agnostic to ingredients and doesn't provide any database. It's up to a user to tag ingredients so tools can recognise them and use in different ways.
It's very easy to update a recipe file in a text format, so there shouldn't be an issue to quickly change names in a recipe you get from your friend overseas.
Not yet solid, but there are ideas. For example, define units config in a way like that: "1l | 1000 ml | ...". The first value will be a preferred one and everything else will be converted. What do you think?
The parser is hand-made https://github.com/cooklang/CookInSwift. I was reading a book "Crafting Interpreters" by Robert Nystrom (fantastic and atmospheric book!) and was eager to try it myself.
This release is MVP, to test the waters. If people like the project we will definitely continue to expand to other platforms. I’m not 100% sure but it might work on windows in WSL already.
It started as a hobby project to solve my personal needs: I really hate grocery shopping: it's repetitive and takes time. I decided to automate it, but couldn't find any robust tools for that. Also for a long time wanted to create a parser and this was a good opportunity.
Current plan is to offer iOS and Android apps for a one-time fee. These apps are based on open-source language and parser (the same used by CLI), but a bit nicer and user friendlier.
The landing page needs a rationale. Why does this product exist? i.e. what problem(s) does it try to solve?
For me, I internalize all my recipes after I've made them a few times. The main problems I face are related to scaling and unit conversions.
So ideally I'd like to publish an interactive web recipe that lets me input the amount of ingredient X I have (or amount of servings I want) and match the ingredient stochiometry in whatever units I choose.
I think the problem it solves is pretty clear: provide a standardized way to easily describe and share cooking recipes, which can further help with building apps or communities around this format.
so if I created tool that could be used to drive nails into wood, wouldn't you ask why I created it? i.e. what's wrong with the hammers we've been using so far?
I'm not saying it's not a useful development, but a good product description helps adoption.
I think when it comes to CookLang, most users don't know of another similar tool, this is why it is attractive.
If you said "I created a tool that can be used to drive nails into wood" and people had no idea hammers were thing, they would probably not ask "why you created it".
Personally I never thought about this (Recipe Markup language) and was surprised to see in other comments that a Schema already exists for recipes, even though the Markup syntax looks a lot cleaner and easier to use.
I admire this effort and wish you a lot of success with it.
I see three main problems:
1) tech people probably do not cook much and more order/eat out, so it is hard for me to imagine chefs/grandmas/not-tech-savvy people using it;
2) main problem for people cooking/experimenting is to decide what exactly to cook - and here you would usually go for something proven (e.g a cook-book or a website)
3) there is a reason not everyone can be a good recipe developer, because it takes a lot of experience and knowledge and you cannot really copy/paste and publish from existing pages/books. I am not sure if I would try a random "forked" recipe.
Good luck, I am interested in what comes out of it!
I don't believe number one to be true at all (anecdotally). Every place I have worked, there's been cook-offs and engineering takes that challenge seriously.
Is anyone working on let's name it CookHub already? So essentially GitHub for receipts. The nerd in me wants to fork receipts and share my small adaptations to the community.