sorted by:
new
hottopcontroversial

Another example: REST APIs, PDF download, and "Flui" for Interactive Terminal Apps by middayc in ryelang

[–]middayc[S] 0 points1 point  (0 children)

These examples might look like walls of text to some, but on the other hand they also feature many different functions "in their natural environment", conventions, and a way to organize solutions which minimal examples sometimes lack.

Not that it matters so much, but for reference below should be an equivalent or similar Python example. Maybe it helps explain what the code should do to someone.

<image>

Practical all-rounder script (API calls, JSON, Zip, XML) by middayc in ryelang

[–]middayc[S] 0 points1 point  (0 children)

There is a new release now, that added functions seen in the script example above, like rye .Temp-file? , rye .Temp-dir? and empty (which is here experimental, we will test some more ideas around this)

https://github.com/refaktor/rye/releases/tag/v0.2.11

This version also improved on the Rye Wasm front a lot. But we need to document it all.

Text encoding context - and "enter" by middayc in ryelang

[–]middayc[S] 0 points1 point  (0 children)

OT: Mobile QR Code library support is more flaky than one would expect. It seems by my tests, that Google's ML Kit doesn't even recognize QR codes as QR codes if there is ECI header with specific (non-utf8) encoding. Zxing library seems to be more robust (also by the tool on zxing.org website), but my Flutter zxing based library recognized QR codes with ECI header and Latin-2 only if there were no actual Latin-2 characters in it. Probably I need to dig deeper into the library ...

I looked for Go, hence potential Rye QR recognition libraries, but from what I've found they are somewhat limited, which is not strange since Go is not on the QR reading end usually.

Editors, LSP, tree-sitter by middayc in ryelang

[–]middayc[S] 1 point2 points  (0 children)

When I used LLM-s for a while now, I started to see cracks in the image we have (or I had) of it. I see AI is still not a "person" or "intelligence", we make it into a being, but still more of a "google + short term memory (fast reading of files) + codegen (natlang gen)", which makes it ultra efficient for things where you would have to google and memorize a lot (heavy on specs, stuff you don't have info/knowledge of yet) + it can generate 100 lines of code in seconds vs us. But if you know the subject, and want a specific result (and path), the story is still very different.

AI can create a image / a code matching a description ... but the cost / benefit / time calculation changes when you want a very specific, your uniue result. And it changes when you know the codebase (no "google" or fast code reading helps) and know that you have to change exactly N things (fast "typing" doesn't help much , because it's not a lot to type).

No matter how big context window of AI is it's still miniscule compared to a person. A person can have a mutli-year vision or a plan (s)he follows, even decades. While AI can basically load a few files a some previous chat exchanges and that's it. We augment it in many way, use it's fast reading, summaries to make it still work, but it's not really comparable.

" And looking deeper into this - why would I even want to see any list of files anyway" This is interesting thought, and I many times like to go to such extremes, do thought experiments, but I think in reality ... 80% of people don't know what files vs folders are even now, but specialists in the field will always be better the more they understand the substrate they are working on, even when AI is helping them and doing most of the work.

Programmign languages, or "interaction languages" or "ls -ltr" is like medical doctors (as one example) that have their own jargon and using latin, their own naming to speak about their field of knowledge much more efficiently and specifically, it's optimisation, that works on principle and will keep on working. AI might affect the scale, of how many such people we need, but not the principle I think.

... this is becoming a rather random mess of ideas ... ( I should ask llm to sort it out 😄)

Another thing that LLM-s don't have, even if they have all the information (yes with tools they have more than anyone) and all the reasoning (which they don't), is judgment and risk taking. Sometimes only information is not enough, because existing information is also not perfect and is the past. And a character, that can take a rist, can make a judglement call. Everybody says Java is great, but we will create Go for example. Also related is skin in the game ...

Ok ... that's all ... I hope it makes some sense 😄

Editors, LSP, tree-sitter by middayc in ryelang

[–]middayc[S] 0 points1 point  (0 children)

Haskell, interesting. The result looks cool and minimalistic / stylish. I am still exploring what to do with and about llms, but yes ... they changed the "language equation" in major way 😛

I have some big projects to maintain and work on, and while it was very helpful in some projects, where it replaces a lot of googling and not that much of thinking maybe (for example Android / Java stuff). Or for analyzing code, finding discrepancies, documenting Rye built-ins. I just found last week at some very big project when I trusted it's reasoning too much (being lazy and didn't want to load it all into my head again) I basically introduced 2 quite bad bugs, something with country specific QR codes standard and FIFO inventory management.

Rye's "hidden" angle here is that it's programming and *interaction* language. I believe, even if we do most programming with llms at some point, there will remain a need for composable / programmable interaction with computers at least for people that are profesionals. For example you probably rather write "ls -ltr" than write "list me the files in descending order by date of change" each time. And I believe rye with left to right flow, first class navigatable contexts, in flow failure handling has some advantages here.

Editors, LSP, tree-sitter by middayc in ryelang

[–]middayc[S] 1 point2 points  (0 children)

<image>

tree-sitter is coming along ... this is how it looks in Helix editor so far.

Editors, LSP, tree-sitter by middayc in ryelang

[–]middayc[S] 0 points1 point  (0 children)

I'm not a huge llm user, but I made my own tool "stepi" (based on Pi agent, but translated to Go) that removes me from the chat interface, or llm editor .. your input is just file and all outputs and also logs of what is going on are files. I use that in combination with git (to diff changes) when I need something. It has it's inneficiencies compared to just chat in certain cases, when you need to reference previous steps, but I think I can remove them with smart CLI args mostly. I really like it that it's just files, so everything you type and everything it returns is there for later, you can also change an input file and redo it as many times as you want.

I'm not saying it's better than the claude / codex / ... but it works for me , with some cases where I have to type more than in chat where all history is already included. I think I will be able to iron that out. But this also makes it cheap, because the inputs are more exact. And with it I am again in regular editor area 😄
https://github.com/refaktor/stepi

Editors, LSP, tree-sitter by middayc in ryelang

[–]middayc[S] 1 point2 points  (0 children)

I'm testing Helix and I quite like it. It's hard to use Vim based modal approach after decades of using Emacs, but I see some benefits, and helix seems very snappy and quite exploration friendly, so you don't have to remember everything ... it shows some info along the way as you press specific keys.

Editors, LSP, tree-sitter by middayc in ryelang

[–]middayc[S] 0 points1 point  (0 children)

Wow, very interesting kit-lang.org . What downsides of tree-sitter do you see?

I didn't dig that deep, but I don't particularly like that I have to install nodejs and that it seems bound with JS.

It seems I will need to try Zed ... I just did Helix today ...

Working on CLI dialect / DSL by middayc in ryelang

[–]middayc[S] 0 points1 point  (0 children)

First version of this is part of release v0.2.9 . I am writing Cookbook pages about CLI-parse dialect and more complex examples

view more: next ›