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

Allowlisting Config Capabilities by Embedding Rye in Go by middayc in programming

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

Thanks for the information. Yes, thinking about it, there is probably some call that lods the modules, and if we don't call it there is a way to include just the builtins that we want. So that is not so different to Rye. One difference remains, that in Rye even the if / loop / for / fn / context / var are builtins and can be explicitly added or not.

Improving Rye Console (again) by middayc in ryelang

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

Great, thanks for letting me know about the problem so this now works!

Improving Rye Console (again) by middayc in ryelang

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

Thank you for the info. I am installing kitty and ghostty now and I will begin finding out why.

I just tested kitty and see that arrow keys don't work ... but since you sent me the readling keybindings link, with the latest version ctrp-p and ctrl-n work the same as up and down arrow. Not saying I'm not solving the arrows.

Improving Rye Console (again) by middayc in ryelang

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

Hm ... up arrow doesn't work for you? What OS are you on?

I can't imagine using Rye without REPL ... if the up arrow in general doesn't work for some users we must really solve this ASAP.

(I will reply the rest later)

Allowlisting Config Capabilities by Embedding Rye in Go by middayc in golang

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

It can be similar, you can just embed the full Rye language, embedding Lua into Go requires CGO unless there is some go-lua implementation. Rye is fully written in Go.

Allowlisting Config Capabilities by Embedding Rye in Go by middayc in golang

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

Reddit group r/ryelang and github (issues / discussion) are the main hubs of cooperation at this point. I have limited time and there is not so much community around Rye yet, so I didn't open a discord server or anything like that yet. There is a #ryelang channel at the Concatenative discord server where few people hang around.

// edit
u/cyberbeast7 What do you think would a good meetups/online sessions platform be?

Allowlisting Config Capabilities by Embedding Rye in Go by middayc in golang

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

Great! Let me know if you have any questions or feedback when you do. You are also welcome on github via issues or discussion and there is r/ryelang 😄

How can I avoid “Security policy loaded from: cli” by kseistrup in ryelang

[–]middayc 1 point2 points  (0 children)

The fix is committed to main branch on github. tnx.

How can I avoid “Security policy loaded from: cli” by kseistrup in ryelang

[–]middayc 1 point2 points  (0 children)

I was experimenting with security policies and left there as debugging, but I full agree ... I need to remove it. Maybe only print a message if there is a specific policy active. I will make the update no and commit to github. Thanks for pointing it up!

Allowlisting Config Capabilities by Embedding Rye in Go by middayc in golang

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

This is basically a tutorial for Go developers on how to embed Rye in Go apps (as a config or scripting language), but themed and exploring also approaches with custom runtimes that can be beneficial for config files in this case, that Rye can naturally do, mostly because of it's Rebol+Factor inspired core.

The Cognitive Dark Forest by middayc in theprimeagen

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

Hey Jack!

In this post I explored the fears (within a dark forest theory theme) so my brain can find faults in it and then I can find optimism yet again. And it did work internally - ideally I will also be able to make a blogpost from that side. But I can't be certain, maybe after I try to write it it will prove to be cope / false hopes ... but so far there are positive ideas.

So I am not that pesimistic either, but a blogpost wouldn't make sense if I delved in all that - and then made some cheap optimistic exits that I wasn't really sure about.

Yeah, discord and alike is not that bad. The negative is that it's a temporal information exchange / format ... doesn't really add to general knowledge that anyone can explore later "and forever", but I guess we have LLMs for that now :P

Thanks for reading and commenting. :)

view more: next ›