middayc

I'm the author of the blogpost / Ryelang. Any feedback is appreciated.

One potential problem, or at least a trust issue, with AI-driven surgeons is the lack of "skin in the game". Or no internal motivation, at least that we can comprehend and relate to.

If something goes off the charts during surgery, a human surgeon, unless a complete sociopath, has powerful intrinsic and extrinsic motivations to act creatively, take risks, and do whatever it takes to achieve the best possible outcome for the patient (and themselves).

But will people have interest in learning a new language? :)

But didn't LLMs read all the math books and can't really do arithmetics (they need special modes / hacks / python to do it I think)?

So why would they be able to "read" the docs and use that knowledge except up to pattern matching level. That's why I also assume, that tons of examples with results would do better than lang docs, but I haven't tested it yet.

@AllegedAlec Rye is fully runtime homoiconic. Rebol had great emphasis on DSL-s (dialects), and Rye has them too (validation, math, ...), but tries to be more conservative with them, because the main Rye DSL should be quite flexible.

Instead of DSL-s Rye focus much more on constructing specialized, also limited and isolated contexts (scopes), that have just the functions you need or just the custom functions you need, while the evaluation mechanism doesn't change (is the one you (or LLM) already know(s)).

I haven't thought about contexts + LLM-s yet. I will read the PDF you referenced with interest! Here is a little more info about contexts: https://ryelang.org/meet_rye/specifics/context/

I googled Alan Kay Steps and got to what seems an very interesting PDF.

I will read it, just to be certain by "might actually help here" - what is "here"? You mean with Rye language design generally, LLM-s relating to new languages or something else? :)

Cool, this explains that idea of code as a tool for thinking in a really good way. Haven't read the whole post yet.

One benefit can be more interactive development, or interaction with the embedded device. I think various forths were used on embedded systems also because of that.

And some projects just don't require much speed and benefit from a higher level lanuage. Reading a couple of sensors over I2C every few seconds, doing some "business logic" and serving data via a http server over wifi can be simpler to achieve in higher level language and the device will be idle for the most of the time anyway.

Micropython is a nice solution in that niche.

But for some projects you do want a lower level language if not for else maybe for lower battery consumption.

It was all cash only. We're not in the US :) ... btw: Slovenia (small country) has more than 1,300 voluntary fire departments, and approximately 8% of the entire Slovenian population are volunteer firefighters. It's the main way especially smaller communities here organize and meet.

The waiters (many, low-trust) were transferring orders to cashiers (few, high trust) by showing them QR code that transferred data to the cashiers' apps.

Then the waiter paid the cashier (in advance), got the bill to give to customer and order tickers (printed on a bluetooth POS printer with a cutter, so they were already separated) to recieve the goods (grouped by stations that gave out the goods, food, drinks ...). The stations took the order tickets and gave them goods. The waiters delivered them to customers and used the bill to get cash from the customer.

The waiters could use their own starting money and just stop selling at any point, or got it from the main cashier and had to return the same amount at the end.

This weekend, my modified Android/mobile Point of Sale (POS) app was used to celebrate the 100th anniversary of our village's volunteer firefighting organization.

The standard fiscal POS app was adapted to support a sort of low-trust swarm of waiters who used the app to collect orders. These orders were then transferred to a few high-trust cashiers by scanning QR codes generated on the waiters' apps.

After receiving payments, the cashiers' apps printed invoices and multiple "order tickets" categorized by "food," "drinks", "sweets"... This allowed waiters to retrieve items and deliver them to customers.

The system was used by around 40 users, with new waiters joining or leaving throughout the event. They used their own phones, and the app functioned without internet or Wi-Fi, gracefully downgraded (If a waiter didn't use the app due by choice or due to technical problems, they could manually relay orders to cashiers), Customers also had the option to approach cashiers directly, receive their order tickets, and pick up items themselves.

This is not that technically interesting, but I liked how the old manual system, the 70+ year village firefighting org. main cashier had, got digitalized in non-centralized way. (and I took this chance in trying to explain it, as I will have to, to maybe find more users for it)

Ryelang has a little different take on this ... op-words and pipe-words: https://ryelang.org/meet_rye/specifics/opwords/

For several years now, my free (programming) time goes into experimenting and making a REBOL based language:

https://ryelang.org

March was quite productive:

* there was major (somewhat breaking) upgrade to the language

* We have a working web (wasm) console again

* full binary builds with some improvements for Windows that before didn't get much attention.

* full function reference with unit tests should arrive soon

I try to post about what I'm working on on Rye's reddit group:

https://www.reddit.com/r/ryelang/

Based on feedback I got, I should rewrite this post, to focus just on 3 Rye examples (starting with the second) and explain them better. Or write another blog post that explains this blog post, with simpler examples for each main mechanism.

One feature I like with CCLM ... it's far less verbose than the LLM-s :)

The author wrote a short comment about each language in the following blogposts:

https://log.schemescape.com/posts/100-languages/index.html

Interesting. I didn't know about this: https://support.microsoft.com/en-us/office/create-and-format...

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

Ok, thanks a lot, for the explanation.

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!

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.

I was asking about "quasidupe". But I don't want to extend this thread any longer.

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?

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).

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?

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 :)

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.

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.

I love looking at AoC solution megathreads on reddit. So many languages and so many different approaches are hard to find and observe anywhere.

I will this year try to be the "support team" for those that will try to do AoC in https://ryelang.org. At least one person said on X.com that he will use it, so we will see :)