7 ms·

What this blog omits to mention and I think the most impressive part of Smalltalk ecosystem is the structure of the image - the application's state that you can

What this blog omits to mention and I think the most impressive part of Smalltalk ecosystem is the structure of the image - the application's state that you can freeze and distribute and resume elsewhere (makes supporting client side applications so much easier). The Smalltalk image is a very interesting beast. Look at it as a kind of immortality. Many current Smalltalk systems, Pharo, Squeak, VisualWorks among them, share a common ancestor, that is, a Smalltalk image from Xerox PARC. This common ancestor however is not some remote thing, but actually still alive in those modern systems. The modern variants were produced by sending messages to the objects in that image. Some of those messages actually morphed the current objects. Classes are full-blown objects, and creating new classes is done by sending messages to class objects. Some of the objects in a Smalltalk image may date back to 1972, when the first Smalltalk image bootstrapped! Smalltalk images never die, they just fade into something potentially fundamentally different. You should view your application building as not fundamentally different from creating a new Smalltalk version.

criddell 11mo ago
> makes supporting client side applications so much easier I was thinking that supporting a Smalltalk application must be a nightmare because it is so malleable. Users can inspect and modify the entire system, no?
- supportengineer 11mo ago
  Correct, at least that was true when I was a Smalltalk developer.
- Qem 11mo ago
  > Users can inspect and modify the entire system, no? That should make the Smalltalk family popular with free software proponents. That makes me curious why that is not the case in history. The efforts of FSF on Smalltalk pale in comparison with those on C, Lisp and other languages.
  - pjmlp 11mo ago
    C was only open until AT&T was allowed to charge for UNIX, and it became an international standard in 1989. It was thanks to GCC that most folks actually got a free C compiler after those events, coupled with Sun starting the trend among UNIX vendors that developer tools would be extra license, no longer available on a regular UNIX installation.
- e12e 11mo ago
  I used to think so, then watched as javascript in the browser rose to be the premium application platform - where the user has access to a console/repl, developer tools etc...
  - sethhochberg 11mo ago
    I think many people would suggest that this was more of an accident due to the ubiquity of the browser, though. The transition from "websites" to "web apps" was well underway by the time the dev tools became a built-in browser feature - Chrome was notable for being the first browser to release with the console, inspectors, etc out of the box, but that came later. The developer experience was quite a bit rougher in the early days, and then better but still not native in the days of plugins like Firebug. The web becoming the premium app distribution platform was, firstly, because the web was the lowest-common-denominator distribution channel. Javascript was just the tool that was available where everyone wanted to run.
    - e12e 11mo ago
      Yes, but maintaining a webapp isn't a nightmare due to the user being able to inspect css, edit html or access the javascript console?
      - NetMageSCW 11mo ago
        The difference is the changes the user can make don’t flow back to the original. If the user hits refresh they get your copy of the web app, not theirs.
- igouy 11mo ago
  > Users can inspect and modify the entire system, no? End users? Yes if you - want them to - let them; No if you - don't want them to - stop them.
- ssdspoimdsjvv 11mo ago
  Smalltalk being so malleable also makes it possible to completely disable source code inspection/execution.
  - igouy 11mo ago
    And then what? Say you made the foreground text color the same as the background text color, so you could no longer see the source code. You can no longer do anything. You can no longer save those changes. And then what? Better, say you did that in a script file which additionally saved the image, so that image was now unusable. And then what?
    - ljm 11mo ago
      Plenty opportunity in many languages or systems to lock yourself out by doing something silly.
    - ssdspoimdsjvv 11mo ago
      The parent comment was talking about a deployed application, and making sure users can't modify the source code. In that case, your image hopefully was built using source code from a VCS and no such changes will have been applied. This is not so different from building an app by pulling the latest version of the code from Git. And if you did manage to commit changes that completely mess up your environment, you throw that image away, take a vanilla one and load your source code into it. Again, not so different from using Git.
      - igouy 11mo ago
        So "possible to completely disable source code inspection/execution" really doesn't matter.
- hboon 11mo ago
  In several implementations you can strip the image down (to remove the dev tools, etc). And some let you ship as single file executables
Scubabear68 11mo ago
The image concept, in my opinion, is what really limited Smalltalk's appeal and distribution. The image meant you basically got whatever state the developer ended up with, frozen in time, with no indication really of how they got there. Think of today's modern systems and open source, with so many libraries easily downloadable and able to be incorporated in your system in a very reproducible way. Smalltalk folks derided this as a low tech, lowest-common-denominator approach. But in fact it gave us reusable components from disparate vendors and sources. The image concept was a huge strength of Smalltalk but, really in the end in my opinion, one of the major areas that held it back. Java in particular surged right past Smalltalk despite many shortcomings compared to it, partially because of this. The other part of course was being free at many levels. The other half of Smalltalk issues beyond the image one, was the cost of both developer licenses ($$$$!) and runtime licenses (ugh!).
- fellowniusmonk 11mo ago
  For this very reason I'm working on a development platform that makes all changes part of a cheaply stored crdt log. The log is part of the application, there are some types of simulations inside of this that we can only timestamp and replay but we can always derive the starting position with 100% accuracy.
  - joshmarinacci 11mo ago
    Ooh. Tell us more.
- lawlessone 11mo ago
  Isn't this kinda where AI is now? Like with LLM's it seems impossible to separate the "reasoning" from data it has stored to learn that reasoning.
- Barrin92 11mo ago
  the entire philosophy of Smalltalk was to think of software artifacts as living entities. You can just find yourself in a piece of software, fully inspect everything and engage with it by way of a software archaeology. To do away with the distinction between interacting, running and writing software. They wanted to get away from syntax and files, like an inert recipe you have to rerun every time so I think if you do away with the image you do away with the core aspect of it. Computing just in general didn't go the direction they wanted it to go in many ways I think it was too ambitious of an idea for the time. Personally I've always hoped it comes back.
shevy-java 11mo ago
That part is also cool. I'd like this in ruby too, e. g. where we could have tons of objects reflect on that state, and just resume work there. Everything is an object. Squeak everywhere, but to also retain the "scripting" (light) commandline approach. Nobody in smalltalk really understood why "scripting" is important. Python showed why.
- igouy 11mo ago
  > also retain the "scripting" (light) commandline approach Smalltalk developers preferred to do their scripting within the Smalltalk IDE, so they could use their familiar tools. And then save their "scripting" as a text file ("fact.st"). $ cat fact.st Stdio stdout nextPutAll: 100 factorial printString; nextPut: Character lf.! SmalltalkImage current snapshot: false andQuit: true! And then "run" that text file ("fact.st") from the commandline. $ bin/pharo --headless Pharo10-SNAPSHOT-64bit-502addc.image fact.st 93326215443944152681699238856266700490715968264381621468592963895217599993229915608941463976156518286253697920827223758251185210916864000000000000000000000000
isr 11mo ago
Adding to what you said. Squeak was a clean open source reimplementation (by the devs who did the original Smalltalk-80), so it's real history starts from there (ie: the 90s, not the 70s) One thing to keep in mind is that smalltalks all have the same ability to save & load code to & from disk, just as any other programming environment. But, they also have the option of just using the image to persist, and iterate on that. Squeak overdid that aspect of it, such that over time, it became hard to prune older side projects & and it just became increasingly bloated. Both Pharo & Cuis forked from squeak at about the same time. Pharo images are fully bootstrapped from a seed. Cuis is not quite there yet, but cuis from its inception went on a ruthless simplification drive (the number of classes in the system was reduced by about 500% !), so that it's base is effectively a "seed", and the rest of a cuis image is built up by importing projects (from disk & git) on demand. But yeah, curating a set of images over time is remarkably enticing & friction free. Even in cuis, I find I have to force myself to keep flushing changes to my own packages. Its not that the tools to use files are limited. In cuis, they're not. You can work on multiple different things WITHIN THE SAME IMAGE (changes to some builtins, a couple of your own projects, etc), and the system will keep track of what belongs where. So a couple of mouse clucks will fileout the relevant code to the relevant changesets & packages. And yet - just banging on the same image is just ... fun, easy, enticing.
- mpweiher 11mo ago
  > Squeak was a clean open source reimplementation Small correction: they actually cloned/converted the Apple Smalltalk image, so those bits remained. The VM was created from scratch by writing it in Slang, a Smalltalk dialect that was essentially equivalent to BCPL and could be translated to C. https://dl.acm.org/doi/10.1145/263698.263754 https://dl.acm.org/doi/10.1145/263698.263754
  - isr 11mo ago
    I didn't know that. So they didn't bootstrap an image from scratch, when they created the new VM?
    - mpweiher 11mo ago
sandcat_ 11mo ago
Unless you are indeed the original author from StackOverflow, it would be polite to attribute your comment: https://stackoverflow.com/a/3617319 https://stackoverflow.com/a/3617319
mccoyb 11mo ago
Are you `robject` on Stack Overflow -- or perhaps you might explain why you copied verbatim their response to https://stackoverflow.com/questions/3561145/what-is-a-smalltalk-image https://stackoverflow.com/questions/3561145/what-is-a-smallt... without citing your source?
aaronbrethorst 11mo ago
Bizarrely, this makes me think of sourdough starter.
- hshdhdhehd 11mo ago
  Anything like that. Dog breeds. Cultivations. Etc.
znpy 11mo ago
Lisps have a similar concept: save-lisp-and-die: https://screwlisp.small-web.org/fundamental/sbcl-slime-eval-lisp-and-die/ https://screwlisp.small-web.org/fundamental/sbcl-slime-eval-... In the world of containers, I wonder if one could use this feature to interrupt the execution of some computation, save the state somewhere (disk or object storage) and once the workload has been rescheduled on some other node, basically you boot up from your image file, re-establish network connections (if necessary) and just resume computation as if nothing happened.
- cben 11mo ago
  https://criu.org/ https://criu.org/ (Checkpoint/Restore In Userspace) is a long-running project (i remember the name over a decade ago) worth checking... Ooh, looks like they made progress in conveniently connecting it to containers.
weakfish 11mo ago
Your comment is an uncredited quote of the following: https://stackoverflow.com/a/3617319 https://stackoverflow.com/a/3617319

criddell 11mo ago

> makes supporting client side applications so much easier I was thinking that supporting a Smalltalk application must be a nightmare because it is so malleable. Users can inspect and modify the entire system, no?

supportengineer 11mo ago
Correct, at least that was true when I was a Smalltalk developer.
Qem 11mo ago
> Users can inspect and modify the entire system, no? That should make the Smalltalk family popular with free software proponents. That makes me curious why that is not the case in history. The efforts of FSF on Smalltalk pale in comparison with those on C, Lisp and other languages.
- pjmlp 11mo ago
  C was only open until AT&T was allowed to charge for UNIX, and it became an international standard in 1989. It was thanks to GCC that most folks actually got a free C compiler after those events, coupled with Sun starting the trend among UNIX vendors that developer tools would be extra license, no longer available on a regular UNIX installation.
e12e 11mo ago
I used to think so, then watched as javascript in the browser rose to be the premium application platform - where the user has access to a console/repl, developer tools etc...
- sethhochberg 11mo ago
  I think many people would suggest that this was more of an accident due to the ubiquity of the browser, though. The transition from "websites" to "web apps" was well underway by the time the dev tools became a built-in browser feature - Chrome was notable for being the first browser to release with the console, inspectors, etc out of the box, but that came later. The developer experience was quite a bit rougher in the early days, and then better but still not native in the days of plugins like Firebug. The web becoming the premium app distribution platform was, firstly, because the web was the lowest-common-denominator distribution channel. Javascript was just the tool that was available where everyone wanted to run.
  - e12e 11mo ago
    Yes, but maintaining a webapp isn't a nightmare due to the user being able to inspect css, edit html or access the javascript console?
    - NetMageSCW 11mo ago
      The difference is the changes the user can make don’t flow back to the original. If the user hits refresh they get your copy of the web app, not theirs.
igouy 11mo ago
> Users can inspect and modify the entire system, no? End users? Yes if you - want them to - let them; No if you - don't want them to - stop them.
ssdspoimdsjvv 11mo ago
Smalltalk being so malleable also makes it possible to completely disable source code inspection/execution.
- igouy 11mo ago
  And then what? Say you made the foreground text color the same as the background text color, so you could no longer see the source code. You can no longer do anything. You can no longer save those changes. And then what? Better, say you did that in a script file which additionally saved the image, so that image was now unusable. And then what?
  - ljm 11mo ago
    Plenty opportunity in many languages or systems to lock yourself out by doing something silly.
  - ssdspoimdsjvv 11mo ago
    The parent comment was talking about a deployed application, and making sure users can't modify the source code. In that case, your image hopefully was built using source code from a VCS and no such changes will have been applied. This is not so different from building an app by pulling the latest version of the code from Git. And if you did manage to commit changes that completely mess up your environment, you throw that image away, take a vanilla one and load your source code into it. Again, not so different from using Git.
    - igouy 11mo ago
      So "possible to completely disable source code inspection/execution" really doesn't matter.
hboon 11mo ago
In several implementations you can strip the image down (to remove the dev tools, etc). And some let you ship as single file executables

Scubabear68 11mo ago

The image concept, in my opinion, is what really limited Smalltalk's appeal and distribution. The image meant you basically got whatever state the developer ended up with, frozen in time, with no indication really of how they got there. Think of today's modern systems and open source, with so many libraries easily downloadable and able to be incorporated in your system in a very reproducible way. Smalltalk folks derided this as a low tech, lowest-common-denominator approach. But in fact it gave us reusable components from disparate vendors and sources. The image concept was a huge strength of Smalltalk but, really in the end in my opinion, one of the major areas that held it back. Java in particular surged right past Smalltalk despite many shortcomings compared to it, partially because of this. The other part of course was being free at many levels. The other half of Smalltalk issues beyond the image one, was the cost of both developer licenses ($$$$!) and runtime licenses (ugh!).

fellowniusmonk 11mo ago
For this very reason I'm working on a development platform that makes all changes part of a cheaply stored crdt log. The log is part of the application, there are some types of simulations inside of this that we can only timestamp and replay but we can always derive the starting position with 100% accuracy.
- joshmarinacci 11mo ago
  Ooh. Tell us more.
lawlessone 11mo ago
Isn't this kinda where AI is now? Like with LLM's it seems impossible to separate the "reasoning" from data it has stored to learn that reasoning.
Barrin92 11mo ago
the entire philosophy of Smalltalk was to think of software artifacts as living entities. You can just find yourself in a piece of software, fully inspect everything and engage with it by way of a software archaeology. To do away with the distinction between interacting, running and writing software. They wanted to get away from syntax and files, like an inert recipe you have to rerun every time so I think if you do away with the image you do away with the core aspect of it. Computing just in general didn't go the direction they wanted it to go in many ways I think it was too ambitious of an idea for the time. Personally I've always hoped it comes back.

shevy-java 11mo ago

That part is also cool. I'd like this in ruby too, e. g. where we could have tons of objects reflect on that state, and just resume work there. Everything is an object. Squeak everywhere, but to also retain the "scripting" (light) commandline approach. Nobody in smalltalk really understood why "scripting" is important. Python showed why.

igouy 11mo ago
> also retain the "scripting" (light) commandline approach Smalltalk developers preferred to do their scripting within the Smalltalk IDE, so they could use their familiar tools. And then save their "scripting" as a text file ("fact.st"). $ cat fact.st Stdio stdout nextPutAll: 100 factorial printString; nextPut: Character lf.! SmalltalkImage current snapshot: false andQuit: true! And then "run" that text file ("fact.st") from the commandline. $ bin/pharo --headless Pharo10-SNAPSHOT-64bit-502addc.image fact.st 93326215443944152681699238856266700490715968264381621468592963895217599993229915608941463976156518286253697920827223758251185210916864000000000000000000000000

isr 11mo ago

Adding to what you said. Squeak was a clean open source reimplementation (by the devs who did the original Smalltalk-80), so it's real history starts from there (ie: the 90s, not the 70s) One thing to keep in mind is that smalltalks all have the same ability to save & load code to & from disk, just as any other programming environment. But, they also have the option of just using the image to persist, and iterate on that. Squeak overdid that aspect of it, such that over time, it became hard to prune older side projects & and it just became increasingly bloated. Both Pharo & Cuis forked from squeak at about the same time. Pharo images are fully bootstrapped from a seed. Cuis is not quite there yet, but cuis from its inception went on a ruthless simplification drive (the number of classes in the system was reduced by about 500% !), so that it's base is effectively a "seed", and the rest of a cuis image is built up by importing projects (from disk & git) on demand. But yeah, curating a set of images over time is remarkably enticing & friction free. Even in cuis, I find I have to force myself to keep flushing changes to my own packages. Its not that the tools to use files are limited. In cuis, they're not. You can work on multiple different things WITHIN THE SAME IMAGE (changes to some builtins, a couple of your own projects, etc), and the system will keep track of what belongs where. So a couple of mouse clucks will fileout the relevant code to the relevant changesets & packages. And yet - just banging on the same image is just ... fun, easy, enticing.

mpweiher 11mo ago
> Squeak was a clean open source reimplementation Small correction: they actually cloned/converted the Apple Smalltalk image, so those bits remained. The VM was created from scratch by writing it in Slang, a Smalltalk dialect that was essentially equivalent to BCPL and could be translated to C. https://dl.acm.org/doi/10.1145/263698.263754 https://dl.acm.org/doi/10.1145/263698.263754
- isr 11mo ago
  I didn't know that. So they didn't bootstrap an image from scratch, when they created the new VM?
  - mpweiher 11mo ago

sandcat_ 11mo ago

Unless you are indeed the original author from StackOverflow, it would be polite to attribute your comment: https://stackoverflow.com/a/3617319 https://stackoverflow.com/a/3617319

mccoyb 11mo ago

Are you `robject` on Stack Overflow -- or perhaps you might explain why you copied verbatim their response to https://stackoverflow.com/questions/3561145/what-is-a-smalltalk-image https://stackoverflow.com/questions/3561145/what-is-a-smallt... without citing your source?

aaronbrethorst 11mo ago

Bizarrely, this makes me think of sourdough starter.

hshdhdhehd 11mo ago
Anything like that. Dog breeds. Cultivations. Etc.

znpy 11mo ago

Lisps have a similar concept: save-lisp-and-die: https://screwlisp.small-web.org/fundamental/sbcl-slime-eval-lisp-and-die/ https://screwlisp.small-web.org/fundamental/sbcl-slime-eval-... In the world of containers, I wonder if one could use this feature to interrupt the execution of some computation, save the state somewhere (disk or object storage) and once the workload has been rescheduled on some other node, basically you boot up from your image file, re-establish network connections (if necessary) and just resume computation as if nothing happened.

cben 11mo ago
https://criu.org/ https://criu.org/ (Checkpoint/Restore In Userspace) is a long-running project (i remember the name over a decade ago) worth checking... Ooh, looks like they made progress in conveniently connecting it to containers.

weakfish 11mo ago

Your comment is an uncredited quote of the following: https://stackoverflow.com/a/3617319 https://stackoverflow.com/a/3617319