https://futureofcoding.org/ logo
Join Slack
Powered by
I’ve been researching spreadsheets and writing one...
# share-your-work
p
I’ve been researching spreadsheets and writing one for a couple months. I wrote a bit about the what and the why, give it a read! https://blog.nilenso.com/blog/2023/11/10/spreadsheets-and-small-software I wasn’t able to cover many specifics here – writing about the work seems like a lot more work than doing the actual work 😅. There’s a lot to cover and I’m hoping to get to it slowly. Until then please shoot thoughts and questions here, I’d love to answer.
y
writing about the work seems like a lot more work than doing the actual work
(cue deafening chorus of agreement from everyone else on this Slack)
This is a great summary and hits all the points I've been wondering about spreadsheets, with plenty more. I didn't know about EUSPRIG, thanks for that link!
Also, I strongly recommend looking at Coda if you haven't already. I've seen so many new spreadsheet tools, but Coda seems (to me, at least) way ahead in terms of both features and flexibility: • Much better formula language than Excel • Lovely UI for writing & debugging formulae • Tons of ways to build reactive documents and apps on top of the data • All the right kinds of product polish (to these eyes, anyway) The main downside: closed source, alas.
There's another problem with Coda that seems inherent to the model of keeping data and computation together: forking is easy (copy the document) but there's no easy way to merge improvements from forks back into the original. It takes careful manual work to separate the data changes from the logic changes, unlike traditional code where the two are already separate. What makes them bleed together is the third circle in your Venn diagram: Presentation. When I add text in a Coda document, I might consider it Data (to be ignored, or swapped with a placeholder) or UI (to be treated as part of the App Logic). Coda, at present, can't tell the difference. I mention it here because the need to fork and then merge logic back to the original is likely to come up pretty quicky.
p
For those with an historical interest, I really enjoyed the spreadsheet chapter in Serious Play by Michael Schrage. It had a fascinating analysis of what made spreadsheets successful and the impact they had in the 1980s on the financial and management worlds.
y
@Personal Dynamic Media Thanks for the tip, I'll check it out! I don't know much about the history of spreadsheets, but I get the impression that they were the original _killer app_: a single app that's so good, it sells the underlying platform. It sounds like accountants would watch a demo of VisiCalc recalculating an entire sheet in seconds and then just whip out their checkbook.
p
@yoz Coda has many really well done things but it falls in the something else bucket imho. I’d say the grid and free form tables are quintessential spreadsheet ingredients. I haven’t spent a lot of time on it but Airtable/SQL-style tables don’t suit general purpose math & programming well.
> It takes careful manual work to separate the data changes from the logic changes, unlike traditional code where the two are already separate. One software analogue I’d apply here are creating different environments of an application – for ex. a staging/QA environment and a production environment for a web app. Keeping them in sync is made possible by versioning schema changes (of the code and the database) separately. This does imply making the separation between schema and data explicit (i.e presentation and everything else). Many more things depend on this separation. The hard bit is to do it in a way that requires little upfront commitment from users.
g
The spreadsheet is clearly the most successful end-user/non-developer programming “language” ever developed. Big fan. A major development a couple years back that doesn’t get remotely the attention it deserves is that Microsoft added user-defined functions to Excel: https://support.microsoft.com/en-us/office/create-custom-functions-in-excel-2f06c10b-3622-40d6-a1b2-b6748ae8231f
m
Kind of related, what is the state of Functional Reactive Programming these days? RxJS (frp-ish), Svelte $:, Elm had FRP then not, Pluto.js, R Reactor, etc. http://herbsusmann.com/reactor It feels like "reactive" systems should be just as ubiquitous as spreadsheets, but it doesn't feel that way.
y
@Mike Austin I don't know about Reactor, but Observable (which Reactor is based on) is still going strong.; the site's code is mostly proprietary but the reactive core is open. Svelte is also doing well, and the upcoming v5 has a bunch of syntax changes aimed at making Svelte more universally usable while substantially reducing weird gotchas.
(And kudos to Rich Harris for this line in the above blog post: "_Like every other framework, we've come to the realisation that Knockout was right all along."_)
Oh, and I forgot about Solid, which seems to come up far more often in random web dev discussions than I would expect.
a
Oh! have you read An App Can Be A Home-cooked Meal? feels similar :>
Open in Slack
PreviousNext
Powered by