I really like the Rye language but my biggest gripe has to be calling tables spreadsheets - so long to type and also implies dynamic, reactive content IMHO instead of static data.
So far I mostly used spreadsheets as immutable data. There are cases when you want / need to change values in-place so how this would work / make sense is being explored now. In immutable data there is no reactive content, because nothing changes.
Immutable approach seems to me to be generally the default one, so maybe we won't delve too much in mutable side, but if we find it useful for specific cases (maybe more directly tied to UI) adding something like calculated columns and or rows wouldn't be hard or of of character for Rye where code and data intermingle often.
Maybe I'll just rename it to table locally and try to use it for a while to see how it feels :)
Now the default mode of operation is spreadsheet as immutable data. So it's not really reactive, but it's still declarable. I am open to renaming it to "table", but I also want to first see where the mutable (spreadsheet as state holding structure) part brings me. Thanks (and also to the similar sibling comment).
The term “table” is already established for this domain, for example in RDBMS.
What you’re building is more inline with that verses the established definition of a spreadsheet.
Keep up the good work though.
I saw Murex Shell ... cool!
* For example, what if Excel wasn't an endless canvas, it would seem conceptually clearer if one sheet was exactly one table with known shape (and you can of course create multiple tables in the same workbook).
* whole column should have the same "formula" and the row for sums / averages and other aggregate functions is not positionaly determined but is more declarative and always on the end.
* header columns are a specific row, not just the first of the rows, or missing
I'm not saying such limited "Excel" would be a better Excel, but maybe it would make more sense, be safer and more predictable, for a subset of users. Anyway ... it's just a sub-experiment.
What negative connotations of Excel do you see?
In the DE space, Excel is the bane of my existence. Some examples of messes we are asked to unravel:
* Cut and paste errors are too easy, once had an an executive boardroom meeting get derailed because one of the execs transposed a column header without realizing it.
* "Who has the most recent file?" becomes a cat and mouse game that sometimes does not have a single answer.
* Just yesterday I dealt with a "business critical" issue where a workbook with >300K VLOOKUPS caused the workbook to become unusable on common workstations - recalc times (with multithreading on) were excessive.
These are common stories, but my biggest issue is reproducibility. Understanding how data arrived at its current state can be impossible, and non/semi technical business users are often not held accountable for an audit trail. At times, Excel being an option is why we don't build more robust solutions, Excel is the gateway drug to failure.
"Spreadsheet" sometimes equates to "a mess", where "data frame" equates to sanity. Reforming the concept of a spreadsheet is a noble goal, but perhaps there is too much history to overcome.
I see too much chance to overwrite something I didn't mean to, or without noticing even. Contrary to Scripts those things are not reversible or reproducible ... I'm not sure if there is some log of changes in Excel.
So at the end, maybe really another reason to change the naming ... :p
Rye "spreadsheets" are rectangular structures composed of rows and columns, like a SQL table or a dataframe.