> 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.
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.
In tech/development, it's akin to someone building a system in some obscure language, because they are most productive and the only ones developing it today.. It's likely that system will end up being entirely replaced if the team maintaining it grows.
(To be clear, I'm not saying the Bakery made a bad choice, or what using obscure languages is a bad choice, or that optimising for immediate productivity through familiar - to you - tools is bad.. just that there is lots to think about when building a new system..)
For new formulas, yeah, It's hard to input new formulas, even in spreadsheet. The system is somehow complex, you probably need a UI for new formulas too, even if it's in spreadsheet.
The reputation of user unfriendliness is undue, and based mostly on looking at how pros work with it.