5 ms·

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 inst

by snthpy 2y ago

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.

middayc 2y ago
Thanks for your feedback. It's still an open issue, as all naming is in Rye. Currently, when I write code with it, I like the word spreadsheet, it somehow gives symmetry to the two usually fat block arguments that follow. I have a lot of ideas I still want to try around spreadsheets, some might work, some not ... so I'm also not sure where the value type will "end up". That might also affect the final naming decision. Currently, spreadsheet and table are the candidates. Dataframe is too technical for what I want to do. 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 :)
- anentropic 2y ago
  Just want to echo the previous commenter - I much prefer "tables" here
- andrewflnr 2y ago
  I want to second the idea that "spreadsheet" implies reactive data, even (or maybe especially) in a programming language context.
  - middayc 2y ago
    When I went into this I was thinking we will have a concept of calculated columns and a calculated row (like option of "sums/avg/...") row at the end. 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).
- hnlmorg 2y ago
  I had very different expectations coming into this thread when the term “spreadsheets” was used. 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.
  - middayc 2y ago
    Thank you for the feedback. Given all the feedback from the others, and now yours, that the word is creating wrong expectations. I am leaning toward just changing it soon and seeing from there.
    - hnlmorg 2y ago
      As a language author and open source maintainer myself, I do sympathise with how hard it is to name things. Keep up the good work though.
      - middayc 2y ago
        Thanks! Well, I name things and try to use them, and usually they cristalize, if not before, then through feedback of others :). I saw Murex Shell ... cool!
nmz 2y ago
lua tables are dynamic and they call that tables
- RodgerTheGreat 2y ago
  Lua "tables" are flat associative structures. Rye "spreadsheets" are rectangular structures composed of rows and columns, like a SQL table or a dataframe.
kermatt 2y ago
Spreadsheet also implies Excel, which can have a negative connotation depending on your perspective. Excel is a double edged sword.
- middayc 2y ago
  I personally am also not that huge fan of Excel, a small reason to name it like this was also to try to challenge that concept a little :) . With something more structured, declarative, immutable and exact: * 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?
  - kermatt 2y ago
    Excel becomes a tool where people without a solid grasp of it use it for _everything_, at times mutating data without knowing it. 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.

by snthpy 2y ago

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.

middayc 2y ago

Thanks for your feedback. It's still an open issue, as all naming is in Rye. Currently, when I write code with it, I like the word spreadsheet, it somehow gives symmetry to the two usually fat block arguments that follow. I have a lot of ideas I still want to try around spreadsheets, some might work, some not ... so I'm also not sure where the value type will "end up". That might also affect the final naming decision. Currently, spreadsheet and table are the candidates. Dataframe is too technical for what I want to do. 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 :)

anentropic 2y ago
Just want to echo the previous commenter - I much prefer "tables" here
andrewflnr 2y ago
I want to second the idea that "spreadsheet" implies reactive data, even (or maybe especially) in a programming language context.
- middayc 2y ago
  When I went into this I was thinking we will have a concept of calculated columns and a calculated row (like option of "sums/avg/...") row at the end. 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).
hnlmorg 2y ago
I had very different expectations coming into this thread when the term “spreadsheets” was used. 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.
- middayc 2y ago
  Thank you for the feedback. Given all the feedback from the others, and now yours, that the word is creating wrong expectations. I am leaning toward just changing it soon and seeing from there.
  - hnlmorg 2y ago
    As a language author and open source maintainer myself, I do sympathise with how hard it is to name things. Keep up the good work though.
    - middayc 2y ago
      Thanks! Well, I name things and try to use them, and usually they cristalize, if not before, then through feedback of others :). I saw Murex Shell ... cool!

nmz 2y ago

lua tables are dynamic and they call that tables

RodgerTheGreat 2y ago
Lua "tables" are flat associative structures. Rye "spreadsheets" are rectangular structures composed of rows and columns, like a SQL table or a dataframe.

kermatt 2y ago

Spreadsheet also implies Excel, which can have a negative connotation depending on your perspective. Excel is a double edged sword.

middayc 2y ago
I personally am also not that huge fan of Excel, a small reason to name it like this was also to try to challenge that concept a little :) . With something more structured, declarative, immutable and exact: * 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?
- kermatt 2y ago
  Excel becomes a tool where people without a solid grasp of it use it for _everything_, at times mutating data without knowing it. 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.