Comment by sebastianconcpt
3 months 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.
3 months 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 →
> you're rebuilding images as you need to, usually starting from a golden master
For example, cp the "golden master" into the current directory and rename it "nbody.pharo_run.image".
"fileIn" the source code file (name passed on the commandline) "nbody.pharo" (and then cleanUp and garbageCollect) and "snapshot" the image.
Then invoke the program "main.st". In this example, the source code file defined a class method BenchmarksGame>>do: which performs a calculation and prints the result on stdout.
https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
It's the "cattle, not pets" mentality.
(There are different ways to manage startup, this is an adhoc simplistic approach.)
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.
> just banging on the system
And then "periodically building a new system image incorporating all submitted code files, and releasing the image for use by the team."
1984 "Smalltalk-80 The Interactive Programming Environment" page 500
https://news.ycombinator.com/item?id=45838056
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.
6 replies →