Comment by seanwilson
7 years ago
> 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.
"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.
There is a downside to this though .. For this bakery, if you hire someone, theres a reasonable chance they can use a spreadsheet (maybe not add new recipes etc, but use..). I'd bet is very unlikely the same will be true of SQL and emacs.
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..)
This is a very important point.
Choose tools that are: (1) right for the project (2) right for the current team (3) right for the future team
(3) might be hard given you don't know who joins later, and the engineers might also not have a say if they're not involved in hiring. But you can generally make decent guesses. The odds of the next baker you higher knowing SQL and emacs? Pretty low... the odds they know Excel? Probably higher.
With that said, this was still fun. I enjoy seeing technology used in interesting ways, even if I don't think it's necessarily the most sustainable way to do something.
7 replies →
Well, he built the system, Emacs is the front end. It's just an awkward front end for most of the people, but with proper training, anyone can pick it up, it's not like ask them to maintain the 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.
2 replies →
For the actual business of making the bread it’s a matter of printing off a single production schedule for the day and taking that into the bakehouse. Touchscreens are a hygiene nightmare in food prep areas.
This is like using a hammer to mend everything around you.
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:
Having to tinker with recipes in SQL sounds really bad as well compared to editing a spreadsheet even if you were an SQL expert.
Yeah, he didn't explain that part well. Bakers typically have ingredients in terms of ratios with respect (usually) to the mass of the main flour. There could be up to a dozen ingredients (sometimes just 3) with time and temperature sensitive processes. A typical small artisinal bakery will have a repertoire of a couple dozen baked goods. It's a fair amount of stuff to keep track of especially when you throw planning/scheduling into the mix.
One doesn't need anything more than a notebook (a paper notebook that is) to do this stuff, but to each his own.
2 replies →
Especially since org-mode has a built-in spreadsheet system that supports formulas written in emacs calc or even arbitrary elisp: https://orgmode.org/worg/org-tutorials/org-spreadsheet-intro...
I really should learn that. I often find myself maniupulating text data in emacs, turning it into CSV or something that I can then copy/paste into a spreadsheet for calculations.
You should. It's surprisingly good. You won't get pivot tables (at least until someone codes them up, which isn't out of the question in Emacs community), but for regular calculations it's awesome.
Here's a short intro: https://orgmode.org/worg/org-tutorials/org-spreadsheet-intro....
Here's some documentation: https://orgmode.org/manual/The-Spreadsheet.html
And if you feel that TBLFMs are getting unwieldy, here's a bunch of features I absolutely love: https://orgmode.org/manual/Advanced-features.html. Turning on an extra column lets you name columns and cells, and have Org Mode recalculate the table automatically on any change, instead of on explicit command.
1 reply →
It can be much easier to do certain things with a proper database than in a spreadsheet if you are familiar with both technologies.