This got me to thinking how chefs come up with recipes. What makes one recipe for tomato soup different to another recipe for tomato soup? Why did they make that change? Is it based on something they read elsewhere, or is it just from experience? Partly it comes down to chemistry (kneading to form gluten strands, or using baking soda to produce CO2), but I’m sure there must be some happy accidents or successful tests that lead to alterations.

So, I wanted to compare some recipes. I started with brownies, as these have a very simple recipe, but also a combination of different ingredients, processes, and subjective measurements. And then I shifted to some pseudocode:


ingredients:
200g of 70% dark chocolate
250g of unsalted butter
360g of caster sugar
4 eggs
65g of plain flour
80g of cocoa powder
1tsp of baking powder

X = recipe:
O = preheat(oven, 180C)
G = line(tin, greaseproof paper)
A = wmelt([chocolate, butter])
B = stir([cocoa powder, flour, baking powder, caster sugar])
C = stir([A, B))
D = beat(eggs)
E = stir([C, D]) until silky
F = fill(G, E)
bake(O, F, 25)

This brought to light a few interesting questions:

• What happens to the variables? Once stir([A, B]) has been performed, A and B no longer exist in that form. Any reference to them should probably fail. If we had B=100g of A then A would then weigh 100g less – or would another variable be created implicitly?
• Which steps can be optimized? If we’d had B = stir([cocoa powder, flour]) and B2 = stir([B, baking powder, caster sugar]), how would we know that the two can be combined?
• Is it possible to tell when operations can be handled concurrently? If there were two cooks in the kitchen, one could have handled the creation of A, and the other the creation of B. But what if creating A somehow impacted the creation of B?

The next step is to make a parser for the above, possibly with some minor changes to address the questions, but I’m keen to keep any recipe language flexible enough to keep the ‘sensual’ aspects, even if it means that it cannot be run by a machine. For me the interest lies in comparing recipes, seeing where processes are equivalent, or taking aspects from one recipe and applying them to another. Watch this space!

You see, the workshops and tutorials were all amazing: I have new-found knowledge of Clojure, Objective C, AWS, and all sorts of other things, not to mention a yearning to apply the coding dojo technique more prevalently. But breaking away from the schedule revealed a whole seam of rich knowledge. Getting time to chat to other coders, to work on little projects, to see what nifty things were being produced – this was what I found incredibly useful. Software development is such a huge area that it’s often overwhelming – language choice alone is boggling sometimes – and knowing how people have fared against hurdles in the past is invaluable. Standing on the shoulders of giants, or even just peering over the shoulders of colleagues, is essential in our field.

So now it’s the day after Dev8D and I’ve actually taken a day to de-geek: to write down all the inspiration that appeared before I forget it and get some of the links and articles stored away to read over the coming weeks. I’m going to get vim set up to do autocompletion; have a play with the Memento APIs to see if they can be hooked into TechTales; dig through some of the tweets for any links I may have missed; come up with a project for my Arduino; and see if I can get some small projects open sourced, so I can let developers peer over my shoulders a little, too. Thanks to everyone who put on such a great event!