Hacker News Reader

Comment by kitd | Hacker News Reader

For me, Smalltalk's "wow" moment was the concept of a persistently running image, with the developer's job being to mould and manipulate it into the shape s/he wants.

View on HN

Ive always "dreamed" of having something like the ST image but backed by persistent virtual memory, not simply RAM.

(Crudely) mmap the ST image to a 100GB file and just change pages. Let the OS flush the pages back and forth.

Maybe full boat, heap sweeping GCs would be Bad as it pages the entirety of the heap in and out. But we have (had) lots of RAM these days. We have generational GCs that leave idle stuff alone. Its no doubt impractical, but I think it would be neat to have the entirety of my historical email in the global "mailbox" array, and I can build indexes off it as I wished. But the mail isn't "on disk", it's all marshalled up as first class objects.

I don't know enough about it, no doubt it "won't work", but the idea of simply mapping the entire, large, ST VM heap to a persistent backing store, just be interesting I would think.

Dangerous too, as there is a demarcation between "running image" and "saved image". But, still think it could be interesting.

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.

Sounds like you would find NixOS and/or Unison interesting!

Yes, big fan of Unison (the system I described above follows its model for code hash identity) and I use a NixOS machine for most of my software work!

Sounds a somewhat like GemStone/S

I think also IBM has or had somewhat similar concepts.

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

Gemstone/S was first an object database, per above article. Vaguely reminds me of:

https://en.wikipedia.org/wiki/InterSystems_Cach%C3%A9

Which I heard about from a friend who was using it at work.

https://en.wikipedia.org/wiki/Comparison_of_object_database_...

Caché is first one in the table.

I remember object or object relational databases were popular at one time. maybe they still are to some extent.

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

For me, that was my "I'm getting out of here before I break it irreversibly" moment while working through some introductory tutorial ~20 years ago; I've never touched Smalltalk again. I can't understand why being bespoke and unreproducible would be a desirable thing for software.

(Yes, clearly I don't "get it". Happy to hear explanations.)

It's unfortunate but understandable that the stuff which is most different from other programming environments grabs attention and the basic stuff is hardly mentioned.

> break it irreversibly

Nope. "Cuis-Smalltalk records any action occurring in the environment: the code you edit in the System Browser, the code you execute in a Workspace. Therefore, in the event of a Cuis-Smalltalk crash you can restore unsaved changes when you launch the same Cuis-Smalltalk image again."

https://drcuis.github.io/TheCuisBook/The-Change-Log.html

> bespoke and unreproducible

So there have been all manner of ways to save code changes as plain text in files (or other formats in databases).

https://drcuis.github.io/TheCuisBook/The-Change-Set.html

https://drcuis.github.io/TheCuisBook/The-Package.html

I have an image with an uptime 2007-2020 and a still working image 50 years old. Images run bit-identical on all platforms because they are byte coded virtual machines

There are Lisps with similar semantics. It faded (further) out of popularity for a number of reasons, but it still has its niche.

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.

It's not widely known, but GNU Emacs works like this.

When you launch the Emacs editor, you're loading an Emacs Lisp image that was populated at build time by running Lisp code, with the resident Lisp definitions "dumped" to make an image file.

The image file used to actually be the `emacs` executable you'd run, using a clever but non-portable mechanism called `unexec` to make an executable.

But as of version 27.1 (in 2020), the image file is separate from the executable for portability reasons.

All Common Lisps can do that, though it is not a part of the standard. See e.g. (sb-ext:save-lisp-and-die)

There are a number of image-based Scheme systems. Chibi Scheme and Chez Scheme come to mind. In both, you can save an image and reload it at a later time, though for very good reasons, most people start each session with a fresh copy of the default image.

CL and Janet both come to mind as supporting image-based deployment.

SBCL does this.

NixOS is kind of like that, the image being the environment you end up with running the system. Difference being you tend to edit the source code of small programs passing/transforming data, package manifests and definitions in NixOS, instead of using the "Inspector" to find and browse live Objects of the image/system and figuring out what comes from where, then running things in the REPL to edit them into the right shape with imperative commands, or use the little widgets to enter/edit data.

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.

Yeah, that perspective also makes sense to me. From my point of view, I kind of use Clojure as a "have live environment + source code" and was mapping that to how I also use NixOS on servers, which basically their shells are remote REPL environments, and my Nix code I deploy to them is the source code in a way.

But the perspective you put forward again also makes sense to me too, I don't think there is any right or wrong here :) Thanks for sharing it at least!

I never made that connection, it makes sense though!

Like LambdaMOO (or my variant of it https://github.com/timbran-project/moor)

or my language https://github.com/timbran-project/mica

I wish this didn’t go out of fashion as much as it did. An environment that you perturb makes more sense in a lot of ways than a “tear it down and restart” model.

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.

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

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.

The only mainstream-ish language where that still happens? R. Too bad, there's a lot more use cases for this sort of thing now - versioning, anything non-persistent agents touch, collaboration, auditable enterprise LOB. It's 2026, why are we (or our agents) still writing serialization code? Even if the AI's write the boilerplate, the state management fragility is often a tax/risk.

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

I fail to see it. But that could really be me. Could you explain how?

The loop and LLM is the runtime, the code on disk/in git is the external state - and the session (dumped and loaded as json) is the image.

The LLM terminal/chat is the repl, and the shell language is natural text input.

Something like that?

Is APL no longer mainstream-ish?

Reply on news.ycombinator.com