Has anybody explored FRP + Spreadsheets? That is, dump the FRP events into a spreadsheet and make that the basis of your programming model? Seems like there’s potential there.

That is a really great question! I had it as well. I took the first few steps (just some HTML events in a table, but you can't do anything with them) to do something in that direction, which I called Streamsheets: https://futureofcoding.org/prototypes/streamsheets/

I'm not exactly sure what that means... but I've often thought that spreadsheets should be broken up into a series of tables. It turns out there is something very much like this called Coda, though it's targeted at end-users rather than programmers.

@David Piepgrass Numbers on macOS embraced the multiple tables paradigm. It helps a little, sometimes—although I’m not a day-to-day spreadsheet person so YMMV.

Yeah, I think I was inspired decades ago by the best office suite ever, ClarisWorks. Too bad it didn't take off, I thought it was far superior to Word/Excel/WordPerfect. So easy to use in its time, and still better than modern implementations in some ways... I haven't seen Numbers tho

Spreadsheet except for graph data is interesting. One problem with spreadsheets and rdbms is that tables are not a fundamental construct in real-world data

@Dustin Getz “tables are not a fundamental construct in real-world data”. Interesting—why do you say so? I’d be inclined to say the opposite, that tables/dataframes are a better fit to most real-world data than any other programming language primitive (lists, sets, sets, tuples, records). Of course, a table is isomorphic to a list of records or a list of tuples, but I think it’s telling that pandas or DataFrames.jl or the R language try to make the table a first-class citizen.

Real world data is nested with references, tables do not have first-class references. For example http://tank.hyperfiddle.net/:demo!seattle/ does not model cleanly as tables

“tables do not have first-class references”—yes, traditionally, foreign-key relationships have been up to the query author to interpret manually via joins. There’s no reason those references can’t be first-class though, other than tradition. The reason I’m pushing back is because I’m hard-pressed to think of a real-world scenario that’s better modeled using nested data rather than some form of normalized table structure that represents the same relationship graph. Back from my web-dev days, I can count on a single hand the number of times I used the JSON cell type in Postgres—it was always some unusual use case. The problem with a nested data model is that the nesting necessarily prioritizes one side of the relationship. Consider the classic example of “Users” and “Posts”. In a nested model, you’d nest the posts under users; but that means to get all the posts to filter, sort, etc, you necessarily have to look at all the users! In pseudocode: map each user to users.posts, flatten the lists, then filter. Normalized tables let you treat both Users and Posts as first class entities: you can query each without necessarily having to route through the other.

Facebook social graph is a graph, not tables In a graph, references can/should be queried in both directions I should not have said “nested”, i need to find a better word that means “graph like”

Are these JSON cells queryable like tables? If not, it makes sense you'd avoid them. Also, JSON is just a tree; a DAG or general graph has more uses.

@David Piepgrass JSON cells support some querying https://www.postgresql.org/docs/10/datatype-json.html#JSON-INDEXING