> 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.

That wasn't a function of the image system. That was a product of your version control/CI/CD systems and your familiarity with them.

Consider that Docker and other container based systems also deploy images. No reason Smalltalk has to be any different.

I did software development work in Smalltalk in the 90's. We used version control (at one point, we used PVCS, which was horrible, but Envy was pretty sweet), had a build process and build servers that would build deploy images from vanilla images. Even without all that, the Smalltalk system kept a full change log of ever single operation it performed in order. In theory, someone could wipe their changelog, but that's the moral equivalent of deleting the source code for your binary. Image-based systems are no reason to abandon good engineering practices.

I agree that the image concept was a problem, but I think that you're focused on the wrong detail.

The problem with an image based ecosystem that I see is that you are inevitably pushed towards using tools that live within that image. Now granted, those tools are able to be very powerful because they leverage and interact with the image itself. But the community contributing to that ecosystem is far smaller than the communities contributing to filesystem based tools.

The result is that people who are considering coming into the system, have to start with abandoning their familiar toolchain. And for all of the technical advantages of the new toolchain, the much smaller contributor base creates a worse is better situation. While the file-based system has fundamental technical limitations, the size of the ecosystem results in faster overall development, and eventually a superior system.

One of the reasons Java got adopted, was that Smalltalk big names like IBM decided to go all in with Java.

It is no accident that Eclipse to this day still has a code navigation perspective based on Smalltalk, it has an incremental compiler similar to Smalltalk experience, and the virtual filesystem used by Eclipse workspaces mimic the behaviour of Smalltalk images.

> 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.

I worked with a similar language, Actor (Smalltalk with an Algol-like syntax), and the usual way to deal with distribution was to “pack” (IIRC) the image by pointing to the class that your app is an instance of, and the tool would remove every other object that is not a requirement of your app. With that you got an image that started directly into your app, without any trace of the development environment.

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.

>> most impressive part of Smalltalk ecosystem is the structure of the image

> The image concept, in my opinion, is what really limited Smalltalk's appeal and distribution.

I'd say these statements are both true. The image concept is very impressive and can be very useful, it certainly achieved a lot of bang for very little buck.

And it also was/is one of the major impediments for Smalltalk, at least after the mid 1980s.

The impressive bit is shown by pretty much the entire industry slowly and painfully recreating the Smalltalk image, just usually worse.

For example on macOS a lot of applications nowadays auto-save their state and will completely return to the state they were last in. So much that nowadays if you have a lot of TextEdit windows open and wish to make sure everything is safe, you kill the program, you don't quit it.

Also, all/most of the shared libraries and frameworks that come with the system are not loaded individually, instead they are combined into one huge image file that is mapped into your process. At some point they stopped shipping the individual framework and shared library binaries.

User interfaces have also trended in the direction of a an application that contains its own little world, rather than editing files that exist within the wider Unix filesystem.

The image accomplished all that and more and did so very efficiently. Both in execution speed and in amount of mechanism required: have a contiguous piece of memory. Write to disk, make a note of the start pointer. On load, map or read it into memory, fix up the pointers if you didn't manage to load at the same address and you're ready to go. On G4/G5 era Macs, the latter would take maybe a second or two, whereas Pages, for example, took forever to load if things weren't already cached, despite having much less total data to load.

But the drawbacks are also huge. You're really in your little world and going outside of it is painful. On an Alto in the mid to late 1970s I imagine that wasn't much of an issue, because there wasn't really much outside world to connect to, computer-wise, and where would you fit it on a 128KB machine (including the bitmap display)? But nowadays the disadvantages far outweigh the advantages.

With Objective-S, I am building on top of Cocoa's Bundle concept, so special directories that can contain executable code, data or both. Being directories, bundles can nest. You can treat a bundle as data that your program (possibly the IDE) can edit. But you can also plonk the same bundle in the Resources folder of an application to have it become part of that application. In fact, the IDE contains an operation to just turn the current bundle into an application, by copying a generic wrapper application form its own resources and then placing the current bundle into that freshly created/copide app.

Being directories, data resources in bundles can remain standard files, etc.

With Objective-S being either interpreted or compiled, a bundle with executable code can just contain the source code, which the interpreter will load and execute. Compiling the code inside a bundle to binaries is just an optimization step, the artifact is still a bundle. Removing source code of a bundle that has an executable binary is just an obfuscation/minimization step, the bundle is still the bundle.

Agreed with that; this is why I think it should unite both the "scripting" as well as image approach, at the same time.

Contemporary Smalltalks support git.

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.

Re: the image concept.

A lot of great ideas are tried and tried and tried and eventually succeed, and what causes them to succeed is that someone finally creates an implementation that addresses the pragmatic and usability issues. Someone finally gets the details right.

Rust is a good example. We've had "safe" systems languages for a long time, but Rust was one of the first to address developer ergonomics well enough to catch on.

Another great example is HTTP and HTML. Hypertext systems existed before it, but none of them were flexible, deployable, open, interoperable, and simple enough to catch on.

IMHO we've never had a pure functional language that has taken off not because it's a terrible idea but because nobody's executed it well enough re: ergonomics and pragmatic concerns.

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.

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.

In several implementations you can strip the image down (to remove the dev tools, etc). And some let you ship as single file executables

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...

> 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.

> 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.

Smalltalk being so malleable also makes it possible to completely disable source code inspection/execution.

Correct, at least that was true when I was a Smalltalk developer.

> 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!

    $ bin/pharo --headless Pharo10-SNAPSHOT-64bit-502addc.image fact.st

> 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