Hehe, this was kind of my thesis back 2015; non public unfortunately, but I think the following is save to share: So basically they had the need to persist huge collections of objects that would not fit into a single servers RAM. As for persistence, a key value NoSQL db was chosen (which is a natural fit for a world where everything has a unique identity - I also have some dislike for ORMs because of that, because I saw how beautiful it could synergize, and how ugly some mechanism are that hibernate, EC Framework etc. have to implement in order to brigde the gap between objects and relational dbs).

The core pattern was that the Proxy, which was under Nil and above all other Objects regarding inheritance I think.

It re-implemented `doesNotUnterstand:` by: 1) First loading the actual object from the persistent storage and 2) sending the not understood message to the actual loaded object (which might be able to answer the message instead of calling `doesNotUnderstand:` for every message, like Proxy did.

There where if course optimisations and so on, but that was the gist of it.

What I really like about this system was that it was completely transparent to the sender of the message whether they were talking to a proxy, or the already-loaded object, all while being robust, easy to maintain and so ob. Dealing with collections was tricky though (how much to load at once? what about searching for a particular object?...), and would have been aswell for deeply nested object (which they successfully avoided though because as a SaaS-company, they could model the data exactly to their needs).

I'm also interested in this and made decent progress on a git-style content addressed image where everything is identified by hash and residency determines what's in memory. For example, there's a filesystem on the image that works this way and you can page over the "cold" non-resident bytes for very large files that you would not want to hold in memory.

You don't persist the state of the full image continuously to the host disk, but any given state (new programs, new runtime state, filesystem) can be saved via a delta, not a full rewrite, due to this representation.

So this is a little different than what you are talking about, but I'd say it's possible.

Did you dream of ColdStore (https://coldstore.sourceforge.net/rationale.html) ?

Sounds a somewhat like GemStone/S

I think also IBM has or had somewhat similar concepts.

https://en.wikipedia.org/wiki/GemStone/S

Huh, I actually think it's the opposite. Classic Linux distros like debian are much more like Lisp, everything is the same big mutable pile of state and you query and edit it from within the system itself. The REPL is just your shell. It's very live and interactive and a bit scary at times.

NixOS by contrast takes the entire Linux userland and makes it an immutable, dead compiler artifact. So it is to debian like C or Rust are to Lisp.

I never made that connection, it makes sense though!

Additionally, although not the same, this kind of relates to JIT caches as well.

Which Lisps were those? I'm kinda interested in this space.

You could argue that a Claude code session also works like a lisp/smalltalk image.

Is APL no longer mainstream-ish?

I think the gnarlier part is that it reveals how much (and how error prone) initialization code is. When objects start glued together in the right structure a lot becomes magically easier to deal with.

I'm considering this for my language but it's a lot more complex to implement (especially with today's ecosystems) and I keep wondering if it's worth it.

Imagine inheriting not your colleague’s code, but his entire machine. Then you discover this machine also is the production environment.