Hack on operating systems and programming languages. He/Him.
Improve tooling for Guile and Guix.
Author of Guix Home, RDE, Arei/Ares Guile IDE.
74830A276C328EC2 at keyserver.ubuntu.com and keys.openpgp.org.
#plt #os #fp #lisp #scheme #clojure #guile #guix #nix #rde #emacs
I have one more reason to make code content-addressable.
Right now people have became much more capable in producing code with the tools like LLMs, but it definitely increases fragmentation and isolation in the communities.
However, we still have a lot to share and talk about and if the code was content-addressable, we could literally see that other people work on the same ideas as we do (even across the boundaries of one language) and communicate and cooperate on these matters.
I receive some positive feedback and even experimentations on SRFI-269: Portable Test Definitions.
https://git.sr.ht/~abcdw/guile-ares-rs/commit/5a16f06221c072353085ded7c54744af97800714
At the same time, I want to remind that we already have a very cool and fancy SRFI-269 test runner with fixtures, schedulers, reporters, integration with Ares/Arei and even CLI:
https://git.sr.ht/~abcdw/guile-ares-rs/tree/master/item/src/guile/ares/scripts/ares-suitbl.scm
And Guile upstream patch, of course:
https://codeberg.org/guile/guile/pulls/294
I guess I'm gradually converting to team- #formalmethods.
I've been writing tests for many years, and I'm very happy with how much better my dev experience has become. Both as a developer and reviewer.
I even spent a year building the coolest testing library for #Scheme.
But the more I work with tests, the more I realize that I want strictier and more declarative way to express system invariants.
The talk reinforces my feelings: