Von meinem iPad gesendet
> Am 17.02.2017 um 18:27 schrieb Hilaire <hila...@drgeo.eu>: > > 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), > I do not understand why we should keep entropy low. There are a lot of side effects that occur in a program. It is not only code changes, it is also creating objects, load external data, etc. Is it possible to draw a clear boundary? If not the side effects collect in every image that does something. So having an image that collects huge amounts of side effects and still runs as expected could be seen as robust system, no? Software does not need to fail immediately, it can also when side effects collect. This you cannot easily catch with tests. Trying to keep side effects low could also mean that you should restart your images often in order to get rid of side effects. So keep an image running and operate with it can be seen as stress test for the software. A usual workflow is to commit code changes, having something like jenkins building your image from scratch. You then copy the built image to server and never save it again. To me it has to do with reproducibility that you need in order to have deployment process. To me it is important to have a working image that collects side effects as well as having a process that builds an image from scratch. Norbert > 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 > >
