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.
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.)
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.
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.
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.
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.
Like LambdaMOO (or my variant of it https://github.com/timbran-project/moor)
or my language https://github.com/timbran-project/mica
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.