zlacker

>>flocia+(OP)
> The key insight is that a bakery formula is so cliched that it can be represented as data. Here’s the formula for seedy malt loaves:

> Of course, that’s not the full set of formulae, because it doesn’t tell you how to make ‘Seedy malt dough’, but that’s just another formula, which consists of flour, water, starter, salt and a multiseed ‘soaker’, where the starter and the soaker are the results of other formulae, which are (finally) made from basic ingredients1. I did consider reaching for the object oriented hammer at this point, but thought that I might be able to do everything I needed without leaving SQL.

There's no way you can do something similar with spreadsheets? The example wasn't in enough detail for me to understand why not. The jump from spreadsheet to SQL seems massive in terms of ease of use.

>>seanwi+e9
"There's no way you can do something similar with spreadsheets?"

You can, but the author is using tools that are more familiar to him, and hence more productive for him.

Just like when doing some quick and dirty analysis, some people will reach for Excel, some for R, some for Pandas. None of those people is wrong.

Some people go too far the other way: spend too much time learning new tools, and not enough creating things of value.

>>rahimn+8a
I'm not saying it's the wrong approach, I'm saying I don't understand what the problem is. The initial example to motivate moving from a spreadsheet to SQL is only this:

    recipe ingredient quantity
    Small Seedy Malt Seedy malt dough .61 kg
    Large Seedy Malt Seedy malt dough .92 kg

Having to tinker with recipes in SQL sounds really bad as well compared to editing a spreadsheet even if you were an SQL expert.