...

Now that FoC stands for "feeling of computing", I can share this — I recently built a new website for Automerge, along with the absurdly talented designer Todd Matthews. The site includes an interactive demo and a bunch of illustrations that attempt to give newcomers a sense of what Automerge does. Like, on one level, we say what it does quite directly with words. But I think it's good to also try to, like, show that somehow, even though it's occasionally a bit abstract.

It was a deeply rewarding challenge, coming up with visuals where every detail (dash patterns, directions of lines, use of shapes) had to be both pleasing to look at but also true to the meaning , and consistent with the other meanings.

You can take something technical — "everyone has their own copy of the data, changes queue, you sync with your peers, everything converges on a consistent state" — and put that into imagery.

Now, of course, I want to actually use the imagery to do the technical thing.

Been thinking how Observable Notebook 2.0 format helps me. I conclude, that kind of transformation should NOT be in the low level. To run Notebook 2.0 you need compilers, but to run Lopecode the format is the low level raw JavaScript so Notebook 2.0 format puts specialised parsers/compilers in the loading path. Compilers and language choices should be in userspace, where they can be changed by the user. So I will revisit Notebook 2.0 when I have fixed the lower layer. I think it be neat as a userspace module.

So I return to where I left off. Bugs in importing from the net. I am redoing the foundational technology. I ditched importmaps and moved over to es-module-shims. It has allowed me to fix a problem that locally loaded models could not be deduped with network imported ones, which ends up causing semantic issues. importmaps are 1-way doors, es-module-shims gives you total control over import semantics at any point in time. Its a really amazing piece of software I recommend learning how it works. It has a C written Lezer parser doing the minimum parsing possible in the fastest possible way to read source code and swap "import" for "importShim" thus enclosing all import calls with a wrapper for customization.

Anyway, in the process I noticed defining the stdlib in the system space was also questionable because half those libs are broken (duckdb) and it takes up 50% of the system overheads for a large amount of extraneous code. Notebook 2.0 redid the stdlib => stdlib is subject to churn. So by a similar argument the stdlib definition should be in userspace too.

I spent a weekend on it and got surprisingly far. I can display some things, es-module-shim dedupuing seems to work and I added a userspace boot module that defines the stdlib and then loads the main module which I think its an improvement and allows the serialization format bootstrap process to be very small (26Kb). In that 26Kb you get a hot swapping reactive runtime and total control over ESM import semantics in a local-file.