> 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.
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.
What he's saying is that it's easier to have the ingredients in a list at the bottom/top instead of strewn around the text. Yes the tools can generate the list but you need the tools. Or read the entire text to parse out the list yourself.
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.
> What he's saying is that it's easier to have the ingredients in a list at the bottom/top instead of strewn around the text.
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.
I didn't see if there was a way to customize ingredients lists, but it a lot of recipes I make and use the ingredients list will be more descriptive of the specific type of ingredient, and in the actual recipe it will just use a general term so it's easier to read, for example the ingredients would read:
* 2¼ cups all-purpose flour, sifted
* 4 medium ripe bananas, mashed
...
and then in the actual recipe it would just say "in a large bowl whisk together the flour, sugar..." and "in a medium bowl, combine bananas, butter, eggs..."
It seems in this lang it seems like it would need to read: "in a large bowl whisk together the all-purpose flour (sifted), sugar..." and "in a medium bowl, combine medium ripe bananas (mashed), butter, eggs..."
It just makes the actual recipe part messier than it needs to be. But like I said, I only skimmed the spec, maybe there is a way to customize and be more descriptive in the ingredients list.
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.
That isn't what I said though. Like my sibling mentions, of course you mention the ingredient. But you don't list the ingredient at the front as "2 cups of butter, melted" etc. and then in the text you say it again "Mix the two cups of melted butter with the 4 cups of sifted wheat flower...". You use short references and that's it.
This is true for pretty much any markup language. If that's an issue for some reason then you can just use plaintext.
The point of cooklang seems to want to be to read well as plaintext though. Like markdown promises. But cooklang does not seem to succeed in that. I find the embedded ingredient with quantity markup destroys my reading flow and doesn't allow me to use the plaintext to actually use the recipe. I have to use the compiler. In markdown I find the plaintext is all I usually need/use and I never compile it to a nice looking document, except if I am trying to publish it for someone else.
This case covers a huge number of the recipes I use, including simple ones like bread recipes.
YMMV. I don't have many such recipes and the few that do work very well in plain English.
I'd also argue that this makes the "default case" easier, as you only need to focus on writing the actual steps involved.
It seems like you're saying that writing a recipe is done more often than reading it. I would question that very much unless you're someone that is like a professional recipe maker.
An argument could be made that it makes reading the markup annoying, but I need to reiterate that markup is primarily for writing.
See above on markdown. I primarily read my `README.md` et. al. in `vi`, not through generated HTML in a browser. YMMV as always.
> 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 output of the CLI tool is suppose to be a better reading format.
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.
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.