[HN Gopher] Spreadsheets 1/3 - Rye Language
___________________________________________________________________
Spreadsheets 1/3 - Rye Language
Author : todsacerdoti
Score : 67 points
Date : 2024-12-21 13:23 UTC (3 days ago)
(HTM) web link (ryelang.org)
(TXT) w3m dump (ryelang.org)
| pvg wrote:
| Threads in the last few months
|
| https://news.ycombinator.com/item?id=41633899
|
| https://news.ycombinator.com/item?id=40947450
| middayc wrote:
| 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.
| pvg wrote:
| Related threads are just that, related threads. Although this
| particular one is what HN calls a 'quasidupe'
|
| https://news.ycombinator.com/item?id=26135382
| middayc wrote:
| 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.
| middayc wrote:
| 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?
| zem wrote:
| 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"
| middayc wrote:
| I was asking about "quasidupe". But I don't want to
| extend this thread any longer.
| pvg wrote:
| 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.
| middayc wrote:
| Ok, thanks a lot, for the explanation.
| snthpy wrote:
| 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 wrote:
| 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 wrote:
| Just want to echo the previous commenter - I much prefer
| "tables" here
| andrewflnr wrote:
| I want to second the idea that "spreadsheet" implies reactive
| data, even (or maybe especially) in a programming language
| context.
| middayc wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| lua tables are dynamic and they call that tables
| RodgerTheGreat wrote:
| Lua "tables" are flat associative structures.
|
| Rye "spreadsheets" are rectangular structures composed of
| rows and columns, like a SQL table or a dataframe.
| kermatt wrote:
| Spreadsheet also implies Excel, which can have a negative
| connotation depending on your perspective. Excel is a double
| edged sword.
| middayc wrote:
| 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 wrote:
| 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.
| middayc wrote:
| 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
| mdaniel wrote:
| 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 )
| nmz wrote:
| in this case its more like rebol and factor had a baby. both of
| which are evolutions of tcl and forth I guess.
___________________________________________________________________
(page generated 2024-12-24 23:02 UTC)