Having worked with Smalltalk a lot I think I know what its main flaw for industrial software development is. It is the image, and your ability to change anything in it (easily), like the Compiler for instance. Then you save your image. Your image is no longer compliant with anybody else's image and the programs you develop "on it" will not run on anybody else's image.
Compare this to a language like JavaScript. There too you can modify the base-objects like Object and Function and Array. But the changes you make to them will be part of your program which is not saved as part of an "image" (only as source-code). Your JavaScript program does not assume anything more about its environment than anybody else's JavaScript program, because you can not develop against a modified "base-image"
(since there is no such thin in JavaScript, is there?).
Smalltalk would be great for things like programming all the smart devices in your house. I think that was part of its original goals, provide an environment where everybody can create their own programs, without worrying much about how your program might later integrate with programs of others.
It's not they don't run on anybody else's image. They might. It is that they are difficult to get to run on other images.
Have you tried porting Smalltalk apps between different vendors' Smalltalks? Problem is there is no standard Smalltalk base-image. That is caused by the fact it is so easy to modify everything in the image you have and then save it and give it to others. Others then start developing against that.
You can try meticulously to avoid this problem but it takes special attention.
Contrast this with Java. You can run any Java program that was developed on a given version of JDK by using that same or later versions of JDK.
I must disagree. Image concept is just a tool, and it only depends on how you use it. In Smalltalk, you can modify the "base-objects" and assign these changes to your package and export them with the other sources (managed by Git, for example), so there is no difference to JavaScript here. But unlike JavaScript and others, you can use the image for things like saving the system state with a debugger open on a bug that is very rare and hard to reproduce.
It is a tool which is very easy to misuse, by forgetting to file out all the changes you make to it.
That is not uncommon in practice. Most (or all?) Smalltalk's come with an image, but there is no source-file telling you how that image was derived, or how you can derive it from some more basic "standard" vanilla image.
That is the reason why it is so difficult to get code developed on one Smalltalk -platform to work on images provided by other vendors. You could say that is caused by "misuse" of the image-tool, but seems like all Smalltalk vendors are doing it.
I ported many projects between different Smalltalk versions, and I never had a bit of feeling that the image concept caused the related issues. Smalltalk implementations are just doing some things differently. The language ANSI standard is too minimal for practical purposes and obsolete. To ruin your basic premise: Common Lisp also uses the image concept, and it is famous for good stability and compatibility among different implementations.
Compare this to a language like JavaScript. There too you can modify the base-objects like Object and Function and Array. But the changes you make to them will be part of your program which is not saved as part of an "image" (only as source-code). Your JavaScript program does not assume anything more about its environment than anybody else's JavaScript program, because you can not develop against a modified "base-image" (since there is no such thin in JavaScript, is there?).
Smalltalk would be great for things like programming all the smart devices in your house. I think that was part of its original goals, provide an environment where everybody can create their own programs, without worrying much about how your program might later integrate with programs of others.