[Rochus]

> For example

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.

[igouy]

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

[Rochus]

> So don't get-rid, now where is "the problem"?

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.

[igouy]

No, not "all development tools used to develop the software and possibly code which is only meant to be used inhouse".

Just the development tools included in the base Smalltalk implementation — we can choose whether or not to include other stuff.

> Of course it doesn't matter for …

Apparently, it doesn't matter for the whole range of business critical applications that do not need to be DO-178 certified.

> In ST80 source code is just an external dump file …

Do you mean that in ST80 source code can be saved as a text file and versioned like other text files?

> Bootstrapping a virtual image …

We can use a base virtual image someone else implemented. (Like we use a JVM someone else implemented, …)

[Rochus]

Well, you were asking.

[igouy]

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?

[Rochus]

I spent much of my life in an with Smalltalk images (some would say too much), and there were also the big names and figures when I did Smalltalk projects in the nineties. Some of the issues could be handled spending a lot of money. The basic concepts (and issues) are the same in all Bluebook offsprings. You probably mean GNU ST; it has the advantage that there is a compiler and library available outside of virtual images and you can use it like a "normal" compiled language and easily re-assemble a virtual image with the objects and versions required. This allows you to use the image as a cache to reduce startup times like e.g. Dart does it. But this is not the original Smalltalk virtual image idea, i.e. not the "whole environment" the fellow referred to.