Ruby and Its Neighbors: Smalltalk

Smalltalk’s Image: Power and Controversy

• Many comments highlight the “image” (a snapshot of the entire object graph) as Smalltalk’s most impressive feature: live state can be frozen, moved, and resumed, even across decades of evolution.
• Others argue the same concept limited appeal: shipped images captured opaque, one-off states with no obvious build recipe, unlike today’s library‑ and file‑based ecosystems.
• Some note that modern systems (macOS autosave, giant shared-library images, Docker) have gradually reinvented parts of this idea.

Versioning, Build Discipline, and Team Workflows

• Critics claim images encouraged “cowboy coding” and made multi‑developer work and reproducibility hard.
• Defenders respond that Smalltalk had method-level versioning, change logs, and sophisticated tools like Envy/Monticello and team workflows since the 1980s; the image should be treated as a throwaway cache, not the source of truth.
• A recurring theme is that real pain points were lack of modularisation and global namespaces, plus cultural habits, not inherent image technology.

Malleability, End Users, and Comparisons with the Web

• Smalltalk’s full introspection means end users can, in principle, inspect/modify everything. Some see this as a nightmare, others as a freedom feature akin to browser devtools.
• In practice, deployed images can be stripped of tools, locked down, and wrapped as normal executables. Some systems also reset state on startup.

Deployment, Tree Shaking, and “OS Within an OS”

• Questions about how commercial Smalltalk apps were delivered get answered: packagers “shake the tree”/strip dead code from the image, add a small native launcher, and ship a single executable.
• The runtime can be made indistinguishable from a normal native app; no development UI needs to be exposed.

Live Environment vs Reproducibility

• Several people praise the “you are in the running environment” experience: halt‑and‑continue, editing missing methods at breakpoints, and zero restart cost.
• Others emphasize that this conflicts with reproducible debugging; they prefer deterministic replays, property-based testing, and database-backed workflows.

Smalltalk, Ruby, and Other Descendants

• Ruby is seen as inheriting Smalltalk’s object model but not its image‑centric workflow; Rails pushed Ruby toward conventional file/VCS tooling.
• Java is said to have “won” partly by being free, integrating better with existing tools, and being championed by vendors who had previously backed Smalltalk.
• Newspeak, Elixir, and modern IDEs are mentioned as spiritual or partial successors to Smalltalk’s ideas, though none fully replicate the original image-centric vision.