[igouy]

The Smalltalk image is just a file, so that's not that difficult to share?

Maybe you mean the Smalltalk code that's been "saved" as part of the Smalltalk image snapshot? In which case, why wouldn't we export the Smalltalk code from the image and share those source code files?

[smackeyacky]

Because poor Smalltalkers often extend stupid things like "Object" and none of their code will run on your image without finding all the changes they made.

So you either try to file out your own changes and merge into somebody elses image, or try to extract theirs for your image.

I realise the state of the art must have moved on since the 1990s but change files back then were a constant source of problems along with how you deploy your image once you are happy with it.

Contrast that with pip or npm. Once I've built my requirements.txt or whatever, I have not only solved how to share my environment with my collaborators, I can use it to build a Docker container and also solve my deployment dependencies.

Smalltalk: play whack-a-mole with change sets until it looks like it's working then strip the image of unwanted stuff and hope it still works. It's caveman stuff.

[igouy]

> I realise the state of the art must have moved on since the 1990s…

A few hours ago you told us "Envy/Developer was in heavy use where I worked" so you know that what you describe was not state of the art even back in the 90's.

https://news.ycombinator.com/item?id=31553494

[smackeyacky]

It certainly wasn't pushed by parcplace. They expected us to use change sets while their own package management was developed.

We ended up going direct to OTI at the time. It about tripled the licensing costs for a smalltalk seat. Due to the costs, it was uncommon in ST shops.

[igouy]

In the bygone days of commercial software tools, vendors sold their own products in direct competition with other vendors.

Presumably y'all paid so much more for Envy/Developer because that was state of art even back in the 90's; not what you described.