(Yes, clearly I don't "get it". Happy to hear explanations.)
(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.
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).
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.
I think also IBM has or had somewhat similar concepts.
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.
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.
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.
or my language https://github.com/timbran-project/mica
All languages that multiply your insight into the nature of computer programming. A bit sad that many just stop at the first of these, and many more don’t even venture past their Pythons and Javascripts.
Nubank (the largest digital bank in the world) using Clojure as their primary driver grew from ~12M customers in 2019 to 131M in 2025 - almost 1000% growth in less than a decade. JPMorgan that has about 80M customers took around 150 years and dozens of acquisitions.
Apple, Walmart, Netflix, Cisco, Amazon - they all use Clojure. Google and Grammarly use Common Lisp.
Check the GitHub language stats and be surprised to see Emacs Lisp among the visible top. There's so much Elisp on GitHub alone - it's just effing crazy. That fact alone at least should be surprising. Remember? This is a not a general-purpose language - it's made for one and only thing, tis a damn configuration language for a text editor. And no, it isn't "some old stuff", check r/emacs - new packages get announced daily! I'm not even exaggerating - new stuff for Emacs comes every single day. Who the heck are all these psychos? Have they not realized how "forgotten" and "dead" Lisp was?
Seriously though, Lisp dialects are enormously practical, it is inconceivable today to find a runtime where you just can't run stuff built with a Lisp. And Lispers keep adding more - Janet, Jank, Jolt, Fennel, Clojure-Dart, Cljbang, Squint - all are pretty young, yet already not some "useless toys" - they're used to build real stuff.
Yes, some people would dive deep into the craft and create works of art, exquisite furniture and tools they need to make it even better.
But those are the few. For the most of woodworkers this is just something they somehow learned to do on a level needed to be able to get a job and make living.
(Agreed that TCL is pretty cool)
Once you start doing that, you move a ladder up in problem solving, where you solve class of problems instead of specific instances.
I think smalltalk and erlang are so interesting because they model the idea of small computers so differently.
Lisp just feels like the purest way to understand what the units of a programming language really is.
I have written a fair amount of Elixir (and targeting business applications) and I think Elixir's expressiveness lends itself well to making more abstract models of the business processes and data seen in solving business problems. However, writing Elixir I find you end up reading a lot of Erlang and in certain problem spaces I could imagine the appeal over Elixir. I could absolutely see where if I were writing more technically oriented programs.... programs closer to the hardware in some ways or programs designed to communicate with other programs (protocols, etc.) I could see Erlang as being a more clear and direct language in these circumstances.
All of this is very hand-wavy, but it's my impression.
Last time I touched Erlang, "Learn you some Erlang for great good!" was fresh out of the printers.
I've just not had time to learn further. As swapping between languages when trying to complete my original Tcl project is tricky. I'm now poking around with Crystal.
A rookie example of erlang and converting strings to base16. I posted in haste a while ago on Tcl's IRC but fun. Never did implement the teddy bear colour.
Other than that, vanilla Erlang is THE way to go.
Millennials catching strays I see.
"claude, run 'npm install' for me"
I find this to be a very strange thing to get defensive about. It's not exactly a subtle part of Elixir's history. It was pretty well documented to be born out of the creator's dissatisfaction with concurrency in Ruby, and simultaneously, for a more Ruby-like language on the BEAM. That doesn't mean it's literally Ruby-on-the-BEAM (which was originally attempted, and didn't work out), however mistaking that as cause to dismiss the link between the two and the carry-over appeal for developers is an unsound overcorrection.
a session prompting Claude to quickly write all of:
a forth style assembler for wasm
targeting a forth written in 6502 machine code (not assembly)
targeting a 6502 emulator/debugger written in Rust
that Rust being compiled into a wasm browser project with
a typescript ui for display api support for all the nested contexts
Is this underselling the role of Self in JS’s prototype-based object system, or saying that a prototype-based object system is not one of the good parts?
The problem is that as beautiful as programing in that sound, we're not even coding anymore, AIs will take the fun of it.
Although, thinking long term and for understendabilitymaxxin and reliabilitymaxxin it might still be worth having something like that.
Since Smalltalk can be so close to english and Erlang VM so reliable, humans and LLMs should thrive on it.
We've come to this. The mere existence of AI is discouraging people from pursuing creative ideas. This is a catastrophe! It's not just taking the fun out of life, it's destroying alternative futures we might have built.
There is this advice for dealing with tyrants and would-be tyrants: "Do not obey in advance." In your case that means pursuing and implementing your exciting ideas.
... it might still be worth having something like that.
Yes! Good luck with it!
experts will emerge from this convenience focused paradigm we are entering so the output quality will certainly improve imo.
Or... Writing a compiler from a large language test suite is already an LLM sweet spot. Writing code which is atypically pretty and readable isn't... but there's at least a possibility of that changing someday.
Imagine a future Lisp-ish culture of "write code to communicate with humans - prioritize readability - machine execution is incidental" and "don't merely solve a problem - write a language for the problem space (and keep it cleanly updated)"... but moving at LLM-catalyzed speed. So much fun.
I suspect that over time a good grasp of fundamentals and great tooling will only get more valuable in software as well as automation expands, in whichever form.
Automation expands the demand for skills. It can never diminish it. Required variety indicates that complexity doesn't go away with automation, and at some level someone will have to understand and make decisions about complex issues. You can't automate all the way down. Or, put another way, everything is already automated all the way down. The expansion of automation as we perceive it is merely the growth of complexity over new dimensions.
Or put a third way: automation means two different things: constraint and liberty. The confusion arising from not discerning which one is in force makes it seems like one can grow unbounded. Liberty requires constraint and vice versa.
That's E and Self erasure.
It ain't a version of Squeak, though.
My favourite thing about it is the lack of "reserved words" - just a handful of punctuation marks. It's incredibly pure - almost all of the syntax is "send this message to this object".
Nowadays I write a lot of TypeScript and prefer having a type system (especially for agentic coding), but Ruby is one of my favorite languages to write myself :)
I still remember writing a Ga Tech themed version of The Sims in Squeak. I felt omnipotent being able to inspect or modify any object while debugging the game mechanics engine I’d written; that was a fun project.
Like what, exactly? I'm genuinely curious. There is no root object or message passing in JS, and the OO aspects are only incidentally bolted on (classes don't actually exist, prototypal inheritance was an afterthought), named params are newer sugar, and polymorphism is a struggle due to all of the above. I've always thought of JS as what Crockford himself said: "a Lisp in C's clothing".