Genuinely useful. The recipe-blog SEO arms race made the open web measurably worse for one of the most basic human needs. Two feature requests: (1) export to a clean Markdown file so I can drop it in Obsidian, (2) a "just the ingredients + steps" print view. Would pay for either.
Range as first-class is the right priority. Pattern that works: keep
ranges as single AST nodes (one dep edge per range, not N), then use
interval trees on the reverse side so a cell change at C5 becomes
"find intervals covering (C, 5)" instead of scanning all formulas.
Pairs well with column-oriented storage if you go there
On the AST caching point, worth caching by structural hash of the
parsed expression, not the source string. Copy paste with relative
references produces different strings but identical AST shape, which
hits a lot in financial-model-style workbooks where parallel columns
share structure
Also worth a look: the "сalculation chain" docs in Microsot's
OOXML SpreadsheetML spec describe how they serialize the dep order
in xlsx files. Different problem (persistence vs runtime) but the
data model is informative for what level of granularity ends up
being practical
This isn't really about R vs Python, it's about grammar matching the shape of the problem.
tidyverse + SQL + Terraform + dbt all have the same trick: the verbs literally ARE the operations, so reading the code IS reading the intent. Pandas, Ansible playbooks, hand-rolled ETL.. they all make you reconstruct intent from control flow. That works fine when writing is the bottleneck. It doesn't once review becomes the bottleneck.
Which is basically the AI era. Writing is free, reviewing isn't. Whichever grammar the reviewer can skim fastest wins the project regardless of what the model prefers to generate.
Kinda ironic given LLMs are way better at pandas than dplyr (training data). So now you've got this weird tension where the model wants Python and the reviewer wants R.