I’m all in favour of making spreadsheets better, with code friendly formulas. Here’s one I’m working on - somewhat earlier in dev cycle than grist and while I did consider Python (and lua) for the formula DSL decided to cook up my own.
not really … I did play with pyspread some time ago tbh i was put off by the basic UI and rather childlike website (sorry I know that’s not really fair, but I am a human). I’ll definitely take a fresh look at it now you mentioned it. curious: what are the standout features of pyspread that you like?
oh and omasheet is Rust and uses Polars so I am working with that rather than NumPy SciPy
Ironically, they kind of tried with New Math. Not SQL specific but the foundations of what it represents. I caught the tail end of it but it's been so long I have no memories of what I was actually taught at the time.
The syntax is so archaic ... it really is anything
but a thing of beauty.
prev_balance = PREVIOUS(rec, order_by="Date").Running_Balance or 0
prev_balance + $Amount
It's such a strange mix-up of stuff. PREVIOUS() is a macro or looks
like one, right? But it is a function call assumingly. But then what's
with .Running_Balance? Guess that also ties into a function. But why
use different syntax for essentially the same thing? It seems rather
weird to write code like that. What would the python variant be like?
Or a DSL?
Does that really convey most easily what is wanted? It seems needlessly
verbose. Why would it require both $Person and $Date? Should that not
be easier to figure out in its own right? Is that efficient?
People need to remember that mentally, unless they use AI.
I think it's an push in Spreadsheets to become more "DB-alike" for less arbitrary results (like in the problem example the article starts out with) but kind-of misguided since it's complicated to do "easy things".
The root issue is that there's almost 50 years of spreadsheet syntax to consider and not colliding with.
That's what makes it clunky. Returning a record is OK, but then a record is basically what spreadsheets are (ala, a table). Except records are named columns in a spreadsheet, and accessing it using a dot syntax looks out of place imho.
I reckon it makes more sense to return a table, and then have an index lookup in that table: e.g., index(PREVIOUS(blah_blah), column). Then you can also use an indirection to choose which column from another cell if desired.
This is how google finance in sheets returns some data (like exchange rates, iirc).
that’s why https://omasheet.org has its own DSL. that said it’s no doubt got some wrinkles so I’ll be reviewing all the comments on this hn post very carefully
I’m all in favour of making spreadsheets better, with code friendly formulas. Here’s one I’m working on - somewhat earlier in dev cycle than grist and while I did consider Python (and lua) for the formula DSL decided to cook up my own.
All feedback good and bad v welcome.
https://omasheet.org
Did you consider trying pyspread?
not really … I did play with pyspread some time ago tbh i was put off by the basic UI and rather childlike website (sorry I know that’s not really fair, but I am a human). I’ll definitely take a fresh look at it now you mentioned it. curious: what are the standout features of pyspread that you like?
oh and omasheet is Rust and uses Polars so I am working with that rather than NumPy SciPy
It supports Python and is Pythonic and being free, matches my budget.
I sometimes feel the world is slowly reinventing BusinessObjects
Imagine a world where we starting teaching SQL in primary school..
Ironically, they kind of tried with New Math. Not SQL specific but the foundations of what it represents. I caught the tail end of it but it's been so long I have no memories of what I was actually taught at the time.
I imagine a world where LLM makes languages like SQL akin to middle English (ie a specialist skill taught to graduates and up)
or better, a Tolkienian incantation
The syntax is so archaic ... it really is anything but a thing of beauty.
It's such a strange mix-up of stuff. PREVIOUS() is a macro or looks like one, right? But it is a function call assumingly. But then what's with .Running_Balance? Guess that also ties into a function. But why use different syntax for essentially the same thing? It seems rather weird to write code like that. What would the python variant be like? Or a DSL?The syntax strangeness continues:
Does that really convey most easily what is wanted? It seems needlessly verbose. Why would it require both $Person and $Date? Should that not be easier to figure out in its own right? Is that efficient?People need to remember that mentally, unless they use AI.
I think it's an push in Spreadsheets to become more "DB-alike" for less arbitrary results (like in the problem example the article starts out with) but kind-of misguided since it's complicated to do "easy things".
The root issue is that there's almost 50 years of spreadsheet syntax to consider and not colliding with.
It is straight Python. Yes the spreadsheet habit of making functions SHOUT does look weird mixed in with Python syntax.
PREVIOUS returns a record, then .Running_Balance pulls out one field of it.
That's what makes it clunky. Returning a record is OK, but then a record is basically what spreadsheets are (ala, a table). Except records are named columns in a spreadsheet, and accessing it using a dot syntax looks out of place imho.
I reckon it makes more sense to return a table, and then have an index lookup in that table: e.g., index(PREVIOUS(blah_blah), column). Then you can also use an indirection to choose which column from another cell if desired.
This is how google finance in sheets returns some data (like exchange rates, iirc).
What parts are Python and how does one know where the classic Spreadsheet functionality ends and Python starts ?
that’s why https://omasheet.org has its own DSL. that said it’s no doubt got some wrinkles so I’ll be reviewing all the comments on this hn post very carefully
hmmm sigils, eh?