Getting rid of objects not belonging to the application to be deployed is difficult or impossible. According to my analysis of the original ST80 v2 virtual image there is a very high interdependency among objects; and since there is no static type information, many dependencies are not statically identifiable. There are also many objects that have not been created or initialized anywhere in the source code (neither in the sources file nor in the Bluebook interpreter), but on which the functionality of the system depends. Versioning of objects and corresponding source code is difficult, also combining a certain version of different components or communication drivers with other parts to be integrated, and so on.
> Compared to what?
E.g. Java or C++ or any technology with clearly identifiable compilation and configuration units.
> Getting rid of objects not belonging to the application to be deployed is difficult or impossible.
1) So don't get-rid, now where is "the problem"?
2) So only add "belonging to the application" stuff to the base image.
> … objects that have not been created or initialized anywhere in the source code … but on which the functionality of the system depends.
3) So those are objects that will always be deployed, now where is "the problem"?
> Versioning of objects and corresponding source code is difficult…
So application source code isn't just text that can be saved in text files and versioned like other text files, and loaded into a Smalltalk image in a scriptable repeatable build process?
Well, not every software manufacturer want's to deploy all development tools used to develop the software and possibly code which is only meant to be used inhouse. And if you e.g. deploy to safety-related targets you even have to demonstrate that there is no "dead code" (e.g. DO-178). Of course it doesn't matter for hobby or non-critical applications.
> So application source code isn't just text that can be saved in text files and versioned like other text files
In ST80 source code is just an external dump file; the actual configuration unit is the virtual image. Bootstrapping a virtual image from source code in ST80 is very difficult or nearly impossible.
From your answers so far, it doesn't seem at-all obvious that were considering disadvantages of "virtual image based systems" rather than particular disadvantages of the ST80 implementation.
Would a Smalltalk image without gui classes not be feasible?
Getting rid of objects not belonging to the application to be deployed is difficult or impossible. According to my analysis of the original ST80 v2 virtual image there is a very high interdependency among objects; and since there is no static type information, many dependencies are not statically identifiable. There are also many objects that have not been created or initialized anywhere in the source code (neither in the sources file nor in the Bluebook interpreter), but on which the functionality of the system depends. Versioning of objects and corresponding source code is difficult, also combining a certain version of different components or communication drivers with other parts to be integrated, and so on.
> Compared to what?
E.g. Java or C++ or any technology with clearly identifiable compilation and configuration units.