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.
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 :)
I want to second the idea that "spreadsheet" implies reactive data, even (or maybe especially) in a programming language context.
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).
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.
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.
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.
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!
Just want to echo the previous commenter - I much prefer "tables" here
Spreadsheet also implies Excel, which can have a negative connotation depending on your perspective. Excel is a double edged sword.
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?
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.
Cool examples, thanks! I haven't used Excel extensively, but I sometimes help at some company where the non-IT founder made complex set of Excel spreadsheets for various things and I rather not touch them at all.
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
lua tables are dynamic and they call that tables
Lua "tables" are flat associative structures.
Rye "spreadsheets" are rectangular structures composed of rows and columns, like a SQL table or a dataframe.
This thing seems like tcl and forth had a baby
Anyway, in the spirit of being helpful I found an asciinema of the spreadsheet behavior https://asciinema.org/a/647708 (from https://github.com/refaktor/rye#asciinema-demos )
in this case its more like rebol and factor had a baby. both of which are evolutions of tcl and forth I guess.
Threads in the last few months
First one was a page full of Rye + Fyne (Go GUI framework) examples and screenshots
Second was about a general Ryelang.org page / language
Current submission is of a longer page about the Spreadsheet data type.
Related threads are just that, related threads. Although this particular one is what HN calls a 'quasidupe'
Thanks for the quasidupe link. I didn't know about it.
This cookbook page is focused specifically on the Spreadsheet datatype, which is similar to dataframes, but also has a lot of specific ideas and views I think. It's not something that other languages couldn't implement.
Page could be a long blogpost, but since it's not temporary information, I made it in a form of a cookbook.
I am the author, but I didn't submit it here. I did submit it on lobsters, and someone reposted it to hn it seems.
Not sure if you will still see this, or if you are the right address, but anyway.
Just thinking ahead ... does this mean that for next 5 months, any subject related to Ryelang is not really desired on HN? For example, let's say that I integrate a game engine and write a post about that with examples and make a live database backend for the Rye contexts. Is this all still considered incremental releases / follow up?
No, it doesn't mean that, it's just posts that are likely to result in a generic discussion about Rye rather than the specific thing being posted are probably going to get moderated as qdupey. Hypothetical example: added some feature and posted the documentation link to it - good chance of qdupery. Blog post discussing something you implemented, a specific problem you encountered and solved (or didn't) in the process, maybe some design you are mulling - probably seen as less of a followup. Posting your stuff + some indication you're around to discuss it - typically also reduces followupness. You can also just email hn@ycombinator.com and ask the mods.
The whole thing is relatively woolly/porous, the goal is to avoid obvious repetition, not to lock you out of posting about your work on HN.
Ok, thanks a lot, for the explanation.
the point of "related threads" is not "this is a redundant post and should not have been made", it's more "other discussions have happened around the same general topic; if you are interested in this post you can go check out the older ones too"
I was asking about "quasidupe". But I don't want to extend this thread any longer.