4 ms·

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

by kitd 1mo ago

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.

TheTaytay 1mo ago
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.
- lilbigdoot 1mo ago
  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.
- fidotron 1mo ago
  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.
- xjdjdkdjn 1mo ago
  Imagine inheriting not your colleague’s code, but his entire machine. Then you discover this machine also is the production environment.
packetlost 1mo ago
There are Lisps with similar semantics. It faded (further) out of popularity for a number of reasons, but it still has its niche.
- Quitschquat 1mo ago
  Which Lisps were those? I'm kinda interested in this space.
  - mike_ivanov 1mo ago
    All Common Lisps can do that, though it is not a part of the standard. See e.g. (sb-ext:save-lisp-and-die)
  - packetlost 1mo ago
    CL and Janet both come to mind as supporting image-based deployment.
  - jlokier 1mo ago
    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.
  - vincent-manis 1mo ago
    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.
  - nobleach 1mo ago
    SBCL does this.
- pjmlp 1mo ago
  Additionally, although not the same, this kind of relates to JIT caches as well.
whartung 1mo ago
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.
- unignorant 1mo ago
  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.
  - dev_dan_2 1mo ago
    Sounds like you would find NixOS and/or Unison interesting!
    - unignorant 1mo ago
      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!
waldrews 1mo ago
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.
- e12e 1mo ago
  You could argue that a Claude code session also works like a lisp/smalltalk image.
  - mettamage 1mo ago
    I fail to see it. But that could really be me. Could you explain how?
    - e12e 1mo ago
      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?
- NetMageSCW 1mo ago
  Is APL no longer mainstream-ish?
cmrdporcupine 1mo ago
Like LambdaMOO (or my variant of it https://github.com/timbran-project/moor https://github.com/timbran-project/moor) or my language https://github.com/timbran-project/mica https://github.com/timbran-project/mica
embedding-shape 1mo ago
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.
- dev_dan_2 1mo ago
  I never made that connection, it makes sense though!
- muvlon 1mo ago
  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.
  - embedding-shape 1mo ago
    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!
morphle 1mo ago
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
mkl 1mo ago
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.)
- igouy 1mo ago
  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 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-Change-Set.html https://drcuis.github.io/TheCuisBook/The-Package.html https://drcuis.github.io/TheCuisBook/The-Package.html

by kitd 1mo ago

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.

TheTaytay 1mo ago

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.

lilbigdoot 1mo ago
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.
fidotron 1mo ago
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.
xjdjdkdjn 1mo ago
Imagine inheriting not your colleague’s code, but his entire machine. Then you discover this machine also is the production environment.

packetlost 1mo ago

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

Quitschquat 1mo ago
Which Lisps were those? I'm kinda interested in this space.
- mike_ivanov 1mo ago
  All Common Lisps can do that, though it is not a part of the standard. See e.g. (sb-ext:save-lisp-and-die)
- packetlost 1mo ago
  CL and Janet both come to mind as supporting image-based deployment.
- jlokier 1mo ago
  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.
- vincent-manis 1mo ago
  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.
- nobleach 1mo ago
  SBCL does this.
pjmlp 1mo ago
Additionally, although not the same, this kind of relates to JIT caches as well.

whartung 1mo ago

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.

unignorant 1mo ago
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.
- dev_dan_2 1mo ago
  Sounds like you would find NixOS and/or Unison interesting!
  - unignorant 1mo ago
    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!

waldrews 1mo ago

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.

e12e 1mo ago
You could argue that a Claude code session also works like a lisp/smalltalk image.
- mettamage 1mo ago
  I fail to see it. But that could really be me. Could you explain how?
  - e12e 1mo ago
    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?
NetMageSCW 1mo ago
Is APL no longer mainstream-ish?

cmrdporcupine 1mo ago

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

embedding-shape 1mo ago

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.

dev_dan_2 1mo ago
I never made that connection, it makes sense though!
muvlon 1mo ago
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.
- embedding-shape 1mo ago
  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!

morphle 1mo ago

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

mkl 1mo ago

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.)

igouy 1mo ago
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 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-Change-Set.html https://drcuis.github.io/TheCuisBook/The-Package.html https://drcuis.github.io/TheCuisBook/The-Package.html