Comment by sebastianconcpt
4 hours ago
It wasn't the image concept. You use it every day in Docker containers for everything else.
But saving the image has some drawbacks. Mutability always requires special care.
4 hours ago
It wasn't the image concept. You use it every day in Docker containers for everything else.
But saving the image has some drawbacks. Mutability always requires special care.
The key is the plural in "Docker containers". You're not doing everything by modifying one Docker container that's been handed down over literally generations, you're rebuilding images as you need to, usually starting from a golden master, but sometimes starting from a scratch image into which you just copy individual files. It's the "cattle, not pets" mentality, whereas a Smalltalk or Lisp Machine image is the ultimate pet.
> You're not doing everything by modifying one Docker container that's been handed down over literally generations
You don't do that with Smalltalk, either, at least not for the last 30 years or so. Smalltalk has worked with version control systems for decades to maintain the code outside the image and collaborate with others without needing to share images.
It’s fun when you realize something that happened 30 years ago is a relatively recent addition to the typical workflow.
1 reply →
I disagree, it really was the image concept, or very specifically how it was created and maintained over time.
A docker container is composed typically of underlying components. You can cowboy it for sure, but the intent is to have a composable system.
The Smalltalk image resulted from the developer just banging on the system.
Except that's not really what happened. You're ignoring the range of in-image tools which kept track if who did what, where. From versioning of individual methods, to full blown distributed version control systems, which predated git.
Not to sound harsh or gatekeep, but folks who keep repeating the canard that "The Smalltalk image resulted from the developer just banging on the system", mostly never used smalltalk in the first place.
Give the original smalltalk devs some credit for knowing how to track code development over time.
No, I haven't ignored those tools. They were all stop-gaps that worked in a "meh" way to various degrees. Smalltalk was always optimized to one guy banging away on their solution. Add a second developer and things got much hairier, and more so as you kept adding them.
2 replies →