Where I ran into trouble was trying to port an app from one Smalltalk to another. Should be easy right because Smalltalk really is a very simple language. But the ways your code could depend on anything in your image are countless. And no standard language definition with conformance tests.
I guess the situation with Smalltalk versions was much like the trouble you have with database vendors today. Or perhaps cloud-providers. Except that Smalltalk was so productive that anybody could easily create their own customizations.
In the database world you can write your own views and stored procedures. But you can't modify the base platform on which you must write those things. In Smalltalk it is very easy to modify the platform, and save those modifications in your image.
IF you had to declare every class and method you use from the image you wouldn't do so much of it. It would not feel very productive having to declare every dependency. But then, you would have fewer dependencies in the end and your code would be much more portable.
Compared to which other 1980's language?
> … smart team working together.
If the team isn't working together the language isn't the problem.
> Where I ran into trouble was trying to port an app from one Smalltalk to another. Should be easy right…
Compared to porting an app between which other 1980's languages?
Say from one C-compiler to another. C is still alive and kicking, Smalltalk not as much as it used to be.
You could write perfectly portable utilities in Smalltalk as long as they didn't rely on any services that were not comparable to what C the language contained within itself.
(Just like "trying to port an app from one Smalltalk to another" would mean trying to port between different Smalltalk gui libraries.)
Even back in 1984 pre-ENVY the explicit advice was —
"At the outset of a project involving two or more programmers: Do assign a member of the team to be the version manager. … The responsibilities of the version manager consist of collecting and cataloging code files submitted by all members of the team, periodically building a new system image incorporating all submitted code files, and releasing the image for use by the team. The version manager stores the current release and all code files for that release in a central place, allowing team members read access, and disallowing write access for anyone except the version manager." (page 500)
1984 "Smalltalk-80 The Interactive Programming Environment"
https://rmod-files.lille.inria.fr/FreeBooks/TheInteractivePr...
> When you depend on (specific facts about) your base-image you don't need to declare such dependencies anywhere.
Why would you do image-based development when you had ENVY/Developer prerequisites "defining exactly which other code an application expects to access"?
https://www.google.com/books/edition/Mastering_ENVY_Develope...
What guarantees such pre-requisites are accurately documented and abided by?
Again if you never save or switch the image it can't give you too many problems. But what's the benefit of image-based development then?
I think it is like GOTO. You don't need to use GOTO even if your language provides it. But it is a bad idea for a language to provide a GOTO because then many people will use it. and shoot themselves in the foot.
Remember when you used ENVY? You could save the image. You could come back next day and pickup your work where you stopped. Even though all the methods were versioned and shared.
I'm saying that using an image and relying on it, having undeclared dependencies on it, saving it and versioning the image has an adverse effect on the long term maintainability and integrability of the software.
Say you had your source-code neatly stored and organized in Envy. Then could you just give your Envy-stored source to some developer in the field-office or an open-source collaborator around the world and say: Use this source-code to develop this further? Probably not. You would ALSO have to say by the way you must use this particular version of the base-image. Right?
And then, when there are several divergent base-images for different projects, how do you merge those base-images?
Envy is the cure to the problem that is reliance on the image. Then you say it is great. Yes because of Envy. Not because of the "image".
What exactly do you mean by "having undeclared dependencies" ?
Doesn't the changes file show everything that's been changed, added or removed?
"Within each project, a set of changes you make to class descriptions is maintained. … Using a browser view of this set of changes, you can find out what you have been doing. Also, you can use the set of changes to create an external file containing descriptions of the modifications you have made to the system so that you can share your work with other users.
…
The storage of changes in the Smalltalk-80 system takes two forms: an internal form as a set of changes (actually a set of objects describing changes), and an external form as a file on which your actions are logged while you are working (in the form of executable expressions or expressions that can be filed into a system). … All the information stored in the internal change set is also written onto the changes file."
1984 Smalltalk-80 The Interactive Programming Environment page 461
https://rmod-files.lille.inria.fr/FreeBooks/TheInteractivePr...
Incidentally multi-site development (page 89) and remote work (page 312) are discussed in "Mastering ENVY/Developer" but here's the part of your comment that puzzles me: you write this as-if it's some-kind-of gotcha?
> You would ALSO have to say by the way you must use this particular version of the base-image. Right?
To make the build process reproducible we start with the same thing and then add, remove and change stuff. Right?
That wasn't because of ENVY. That was something that would be written as a Smalltalk script — because reproducible.
But things got tricky when different people use different base-images and it is so easy to create new base-images. When you depend on (specific facts about) your base-image you don't need to declare such dependencies anywhere. Combine that with dynamic typing of Smalltalk. Then when you try to move to a different Smalltalk things just don't work and it takes time and effort to figure out why.
I guess the way to do it would be to never save your image, but that is so easy and convenient. But if you never save your image, it is as if you are not using the feature of having the "image", so you can't really say it is a good feature if you never use it.
When you do image-based development it is hard to control what and how many dependencies you create that are dependencies on the image you are currently working in.