Improving seccomp and landlock intergration into https://ryelang.org, improving tooling for making single executable files from rye projects, experimenting with reactive, declarative TUI library.
I was never an iOS user, or developer - exactly because Android was more "open", exerted less control over a user of the device.
The same reason I use Linux for 25 years (not ideological, but it just makes most sense by far). In time where this view (win11 vs. Linux) is starting to make sense to more and more people, few rare config nuances are getting easier to solve due to LLM-s, going into the opposite direction with a mobile OS calls for users to also start seriously considering more open alternatives and making a path for users of our app to do the same.
They're static lists that won't get updated unless we add to them manually. I'd love to make them auto-update (see https://hackernews.hn/item?id=46610744) but that might be too much to expect for now.
But it reminds me of the SEO guys optimizing for search engines. At the end of the day, the real long term strategy is to just "make good content", or in this case, "make a good language".
In the futuristic :) long term, in "post programming-language world" I predict each big llm provider will have its own propertiary compiler/vm/runtime. Why basically do transpiling if you can own the experience and result 100% and compete on that with other llm providers.
It's interesting how often there are similarities between Numshell, Rye and Lil, although I think they are from different influences. I guess it's sort of current zeitgeist if you want something light, high level and interactive.
Yes, a lot of REBOL ideas, that Rye took, or various functional, homoiconic langauges implement (haskell, lips, clojure, scheme, Io, Factor) come from search for greater internal consistency than your ALGOL-derived status-quo languages provide. :)
So degrading the core doesn't make much sense if you are not more specific. This is the core.
The `6` is the code, I just put the first thing that came to my mind there :D
In my example, if you replace it with a more sophisticated code block, R will evaluate it and print out the result of the evaluation.
Typically, you'd want to parse the unevaluated code, though:
> `if` = function(a, b) { print(substitute(a)); print(substitute(b)) }
> if (foo) { print("bar") }
foo
{
print("bar")
}
It overwrites `if`, in the current scope, of course.
reply