You have a very strong point. The problem you emphasised, without explicitly naming it, comes from the image. Because the image preserves state it is also a great receptacle and accumulator for entropies, and as we know entropies only increase, never decrease! The direct consequence is that, at some time, after some interactions, installing code in some order, or installing broken code, an image breaks, hit the ground and becomes unusable. The image limit is always the chaos (as long as it is used as a living thing and its evolving state is preserved, saved),
Entropies always comes with interacting 'living' system. So Smalltalk image comes with this downside of entropies. I don't see how you can bring argument against that to developer team, because it is the Smalltalk weakness, as well its strong point. Very funny. Of course you can try to limit entropies. Versioning your image is probably what to do, for example host task could save version of your image every two hours, daily, etc. GNU Smalltalk took an original approach: it ships a minimal image you don't modify and you install code on top of it. So really you never save your image, entropies remains constant over time. This approach is not really possible with Pharo. Best wishes Hilaire Le 15/02/2017 à 23:43, horrido a écrit : > In file-based word, the answer is tests and CI. What is the smalltalk way? > And please do not say "It's in the conceptual nature of programming" -- if > the scenario makes no sense in the smalltalk world (maybe you are not > supposed to have 20 people working on the same project?) please say this. > > ----- > > How would you respond? I know Smalltalk can be used in large team > programming, but since I personally have no experience with this, I cannot > respond intelligently. -- Dr. Geo http://drgeo.eu
