The author states that they believe EventStores are more valuable because they maintain context whereas datomic's records changes without context. Datomic arguably leaves other things out... it doesn't, for example, truly provide an entity kind or a firm consistent schema. It's up to application code to define more formal relationships of data kinds. Arguable you could also say it's up to the application to capture context changes. I do wonder if a hybrid model between these two would result in an overall better solution.

An early thought here... there are a lot of micro decisions that have to be made when building out a view layer. Reducing the design space is a necessary component to prevent analysis paralysis. I'm reminded of Charles Chamberlin's Apricot

This is often a barrier for me. As a matter of fact, I've got a big life decision to make that I keep putting off because I don't feel like I have a good enough plan. Unfortunately, the plan is work too, ha.

Found from https://twitter.com/matt_dz/status/1653145441590968320

I got here by searching how to persist a graph in a key-value store.

This was my main question too. It seems like a novel exploration, but definitely not untenable in most software systems given the inability to restrict things like global variables.

TIL. Makes sense though.

A compelling insight.

Ever the challenge of relying on dependencies. A necessary tradeoff, but a tradeoff non-the-less. This loops back in to something that I've been thinking recently which is that our means of sharing code is critical to the overall stability of software. No code sharing solution obviously isn't ideal but modern package management leaves something to be desired. I think languages that handle this as a first class feature (https://www.unison-lang.org/, https://scrapscript.org/) have a leg up in this regard.

I've been reading a lot more about capabilities lately. This reminds me of the Capability-based computer systems paper by Henry M. Levy that was published in 1984

https://homes.cs.washington.edu/~levy/capabook/

I hadn't heard of LlamaIndex before. It can be found here: https://github.com/jerryjliu/llama_index

A summary from the repo:

LlamaIndex (GPT Index) is a project that provides a central interface to connect your LLM's with external data.

A simple yet profound observation.

A few other good (related) resources: - http://ravichugh.github.io/sketch-n-sketch/ - https://maniposynth.org/

This is really fascinating. I wonder if the replay.io folks would have thoughts on this. It seems like the closest we could get today is a QuickJS integration (though it's notable that QuickJS doesn't seem to be that actively maintained these days). I do wonder if perhaps a language that's more embeddable (like lua) would be a better fit?

This is fascinating! I wonder what other mathematical expressions other relationships from statecharts would bring?

Interestingly this is part of the problem David Harel sought to solve when coming up with statecharts. As per the abstract of Statecharts: A visual formalism for complex systems

Our diagrams, which we call statecharts, extend conventional state-transition diagrams with essentially three elements, dealing, respectively, with the notions of hierarchy, concurrency and communication

https://www.sciencedirect.com/science/article/pii/0167642387900359

This is a fascinating aside! #note-to-self read up more on the early history of parsing techniques and AI research.

Haha, I love the little GoF (Gang of four) super script! Link decorations aren't used nearly enough imo.

I'd love to see this sort of feature exposed more often from programming systems. Portability is huge and being able to easily share software is (or should be) one of its most important aspects.

I really love the design of this page. It's clear and to the point. The little wikipedia supertext icons and hover cards are amazing.

This seems to suggest structural typing. It makes me think a bit of components in Entity Component Systems.

b/c the highlight formatting is terrible, I'll repeat it below

1. Separate code from data
2. Keep data immutable
3. Represent data with generic data structures

This makes me think of StateML's approach to state charts. Essentially they define state charts as a simplified DSL that externalizes all behavior and contextual state to the executing system. If a similar approach was taken with Cambria then you could specify that external behavior was required to do a certain type of manipulation and leave the specifics of that out of the lens. The tradeoff here is that the lens itself isn't sufficient to do the translation fully, but it does remove the necessity from adding a full turning complete language inside the lens.

I think the key aspect here is that this highlights an incompatibility point that requires migration. Also, this makes me wonder if expressing complex transformations breaks outside of a simple DSL?

My interpretation of this section is that transformation should happen on the outer bounds of a system not its inner bounds. E.g. in a web application you'd want translation happening at the API layer, not at the database layer.

So the ability to specify at some point that users must upgrade is a key component. That doesn't necessitate requiring it all the time, but it acknowledges the reality that it may happen.

I think this is really key. While Cambria (and approaches like that) help provide some approximation of compatibility, whether that is sufficient or not really depends on the underlying semantics of the translation.

So the mapping property of convert is a 2-element array with the first element representing the transition from original to evolved and the second element representing evolved to original. I would've likely kept them explicit.

This is interesting as it means there's at least one unbreakable promise that must be provided.

lenses are an interesting concept that already exist as a concrete notion in software. The language Racket has a notion of a lens that it defines as

A lens is a value that composes a getter and a setter function to produce a bidirectional view into a data structure

https://hyp.is/LrFtPsq6Ee21rSsGHCRKRw/docs.racket-lang.org/lens/lens-intro.html

See also the mention of lenses later in the document: https://hyp.is/V6TPVsstEe2G1a_KcmF7ww/www.inkandswitch.com/cambria/

They explicitly link the Edit Lenses paper by Hofmann, Pierce, and Wagner

I didn't realize this!

I want to understand how Cambria resolves this too. The dates are signifiers for breaking API changes... It seems to me that you wouldn't want anything other than a single linear migration path. Though I guess the argument here is for local first software where you may end up hitting a mix of newer and older version endpoints. The entirely tricky thing here is that it's easy enough to reason about what's a backwards breaking change but technically any new field becomes a forward breaking change. Resolving that seems like a challenge.

I don't (yet) see how cambria avoids this. I suppose it entirely depends on what they mean implement translations by hand. From my perspective having a DSL to accomplish the translation doesn't make it any less by hand nor does it remove the necessity of needing test coverage for the translations. I suppose it could lessen it to some extent?

Haha 🔥

Another awesome article. I didn't really understand abilities before this aside from knowing they were some sort of algebraic effect implementation (which I also didn't understand).

The exceptions example and the note about dynamic scoping helped me tie it together mentally. It's like exceptions except it's two way, not one way. It bubbles up to some point, is handled, and then the calling code resumes.

So g is just a generic catch-all for abilities

I'm not sure what a watch expression is...

This is fascinating. Not disputing what they're saying here, but react's whole suspense system kinda works in this way. When it suspends it's actually just throwing a promise that, when resolved, lets react's scheduler know it's okay to continue. Internally it's probably doing some crazy rehydration of the internal state of the component but that's effectively how I understand it to work.

It's cool that unison has a this mechanism first classed.

So when you're defining a zero-arity function in unison, prepending an ! executes the function.

E.g.

func = '42

!func -- reports 42

This is interesting... is that what a thunk typically is?

So.. it gets some setup and teardown data?

This is really fascinating! In some ways this makes me think of React's context which enables passing data deeply down a component tree.

Fantastic article on how unison uses content addressablity to ensure renaming things doesn't break the world.

It's notable while this is true for internal system concerns it may not necessarily be true for external system concerns. It does avoid the whole left-pad situation though.

I'm not familiar with the concept of an image in smalltalk.

Here's what wikipedia has to say:

Many Smalltalk systems, however, do not differentiate between program data (objects) and code (classes). In fact, classes are objects. Thus, most Smalltalk systems store the entire program state (including both Class and non-Class objects) in an image file. The image can then be loaded by the Smalltalk virtual machine to restore a Smalltalk-like system to a prior state.

https://hyp.is/JSSGksUWEe2szz-6MaOv-w/en.wikipedia.org/wiki/Smalltalk