Spritely Institute

That is why I created https://codeberg.org/ZelphirKaltstahl/guile-examples. I like GNU Guile and many things exist, even in the batteries that are included, but are not easy to find or one needs to figure out how to effectively use them. Also got an awesome list somewhere, but I need to migrate that to codeberg later.

Compared to some other languages, the ecosystem is small though. While in Python often you have 3 or 4 libraries solving the same or similar problem, in GNU Guile you often only have 1 or need to write your own. Knowledgeable people are able to quickly throw something together, or call out to C libraries using FFI, but I have not done FFI yet. Some day I really should look into that ... And into Hoot by Spritely Institute [1]

If one wants to check out more algorithmic stuff, I also have some stuff on that: AoC 2024[2] (and previous years too), and guile-algorithms[3] (not that much yet, but useful things, and trying to keep it fully functional). Some time ago I also wrote a toy implementation of a decision tree in Guile[4]. It is even parallelized and achieves linear speedup in my tests. I call it a toy, because you will have to do all the data preparation yourself, because it only deals with numbers, and there are probably smarter ways of storing the data for each node, maybe even avoiding duplication. There is also no library like numpy or dataframes like in Python, so I am using possibly not so optimal data structures. But it is probably worth checking out…

Bell Labs is wonderful to read about, and I've really loved delving into it. Alan Kay's talks in particular.

However, it should be seen as a starting point! Alternative hypothetical pasts and futures abound. One issue is that the stuff from the past always looks more legendary seen through the lens of nostalgia; it's much harder to look at the stuff around you and to go through the effort of really imagining the thing existing.

So that's my hypothesis - there isn't a smaller volume of interesting stuff going on, but viewing it with hope and curiosity might be a tad harder now, when everyone is so "worldy" (i.e., jaded and pessimistic).

Proof:

https://worrydream.com/ (brett victor)

and the other people doing dynamicland and realtalk, both discussed straightforwardly here:

https://dynamicland.org/2024/FAQ/

https://solidproject.org/about -- solid, tim berners-lee and co, also.

https://malleable.systems/catalog/ -- a great many of the projects here are in the same spirit, to me, as well!

https://spritely.institute/ -- spritely, too

https://duskos.org/ -- duskOS, from Virgil Dupras

https://100r.co/site/uxn.html -- 100 rabbits, uxn, vibrating with new ideas and aesthetics

https://qutech.nl/ -- quantum research institute in the netherlands, they recently established a network link for the first time I believe

etc etc. These are off the top of my head, and I'm fairly new to the whole space!

Nah thanks, I'll stick with ActivityPub.

The fact they even felt the need to create another protocol instead of using, improving and contributing to ActivityPub makes me think they want to bake a busines modell for themselves into the technology and they can't do that if they don't have full control over the spec.

ActivityPub is organically grown from a community to serve that community.
Bluesky is created to combine making the profits of a commercial centralized social network + profiting from the investment from crypto bros.

ActivityPub is not perfect and nobody is pretending like it is (there is a big blog post from the co-author about what retrospectively they should have done differently, sadly I couldn't find the link), but a specification is not static !
If you have a suggestion to improve it you can propose changes and a lot of things are left to the implementation, so you can just do things differently than other ActivityPub application currently do.

In fact there are people building the future of the ActivityPub ecosystem right now: https://spritely.institute/

There is no need to create yet another specification.
The only feature this claims to have, that all ActivityPub implementations currently don't have is identity portability and that can actually be implemented without changes to the ActivityPub spec, just no ActivityPub Application has implemented it yet.

I mean, they're pretty much the same right? You can't abstract away the services and you need to pass arguments to the executable (ntpd in this case).

I don't see more or fewer issues, but I also don't see the value to using Scheme instead of a conf. file like format.

At the end, there's talk about adding the possibility to live reconfigure services, which is pretty cool but I don't really see what kind of users are targeted by that use-case, at least not regular users like me who's running Linux on a single laptop.

The link at the end (https://spritely.institute/news/spritely-nlnet-grants-december-2023.html) is IMO much more interesting since it would make it possible to orchestrate several machines and their services as well. If you have live reloading as well, I think it would make for good developer experience.

My main gripe with Guile is its ergonomics and tooling: no LSP, no linter, no step-debugger that I know of and the docs are often unhelpful imo.

Maybe I'm not Scheme brained enough but I think it's a shame because there are some really cool projects out there (anything https://spritely.institute/ really).

P.S: I know that some people will tell me to get used to REPL based development which I think is fine for small-ish projects but I can't understand the flow one uses for larger projects where many components might need to talk to each other.

> It isn't onerous. Here's an example using Scheme in the browser:

> https://www.spritely.institute/news/building-interactive-web...

That looks pretty damn onerous to me:

1. (Guile) Declare all the JS symbols you wish to use.

2. (JS) Write wrappers for the symbols from #1 above.

In short, you're still writing custom glue code for manipulating the DOM from the wasm language, and you'll need more custom glue code if you ever want to call your wasm functions from JS (for example, from the `onclick` attribute in an element tag, from `setInterval()`, from resolution of a promise, etc).

This is not what I meant by my response in the following exchange:

>>> It's true you have to use JavaScript glue code, but it's also true that won't be true forever.

>> I won't live forever and I'd like to deliver my product before I die.

Right now, it is true that wasm DOM access is non-existent, needs glue code to be existent, and the DOM <--> wasm interface, even with glue code, is limited as hell.

I don't know if there are plans to address this. It is irresponsible of me to use wasm for a client today under the assumption that, by the time I need a DOM <--> wasm interface, it will be there.

Before the limitations of the DOM <--> wasm interface is ever addressed, the product might even have reached end of life.

The animation on the Syndicated Actors home page [0] does a pretty good job of showing the difference, I think. Goblins is much more similar to the classic actor model shown at the beginning of the animation. The "syndicated" part, as far as I understand, relates to things like eventually consistent state sync being built-in as primitives. In Goblins, we provide the actor model (actually the vat model [1] like the E language) which can be used to build eventually consistent constructs on top. Recently we prototyped this using multi-user chat as a familiar example. [2]

[0] https://syndicate-lang.org/

[1] https://files.spritely.institute/docs/guile-goblins/0.17.0/The-_0060_0060vat-model_0027_0027-of-computation.html

[2] https://spritely.institute/news/composing-capability-security-and-conflict-free-replicated-data-types.html