[protocontrol]

Although it's true that today it is easy for everyone to write, even those who have no experience or have had a disappointing experience, the effects of what they write are often not measurable. That is, it is easier to measure the resources needed to write than to measure its effects.

Smalltalk is a tool for the creative spirit. It's a very powerful tool for those who have something inside and want to develop it. On the other hand, nowadays, the alternatives that are massively propagated have other characteristics. They are for those who feel better (or calmer) absorbing what someone else has done. They are for those who hide behind the phrase "it is better to ride on the shoulders of others" trying to show wisdom, but in reality revealing dependency and unproductivity.

The problem with Smalltalk is that in computing, the "creative spirit" is a dying breed. Smalltalk is for the creative. Most think that creating is expensive and settle for copying (imitating) or using (claiming to re-use!).

Whoever thinks someone has something to contribute, let him use a Smalltalk, whoever doesn't, let him buy the latest.

[smackeyacky]

Contribute to what? If you have something that is fundamentally difficult to share (like a Smalltalk image) what are you contributing to other than entropy?

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