Comment by chuckadams
3 months ago
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.
I try not to think about these things, I've mostly worked with hardware-centric companies and on "legacy" systems. So many things they're doing that no one else does because 5-25 years ago everyone else figured out the lessons from 30-60 years ago, except for these companies.
> 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.)