Am 02.05.2011 um 18:49 schrieb Ted F.A. van Gaalen: > Hi All instances of HumanBeing > > Then, another question remains: > > Will my image of 2011 still work correctly > on the VM of AD 2019 (the ones that than probably > run on Ubuntu 2019.10, Windows11 and AppleOS/X 2019)? > or the VM created for a newly emerged computer system? > Well, forecasts are always hard to do. Basically I would say if you can get the current vm running on these releases than your image should run as well. If it doesn't run you need to think why you need such a new system. And you need to think whom to blame: intel, amd, arm, canonical, microsoft, apple, the linux community or the squeak/pharo community.
> "All" I wish for is: > -= Backward Source Compatibilty =- > whenever possible because: > -in five years the one could have written a huge amount of coding, > for instance, a large ERP system, or an large internet trading > system. Often these consists of (10)thousands of lines > of coding, even in Smalltalk. Many years of development and > effort, blood sweat and tears have gone in to it. > Finally everything is debugged and tested. And may happy > users depend on it > If it ran for 5 years without the need for a change where does this need come from out of a sudden? > Assume that throughout this all coding are countless > references to classes that are perfectly normal at the > time of writing. This no exception. > Well, if you stay in this "time of writing" (meaning same vm, same image) everything should be fine. > Then one or tow releases later: > > If these classes are removed, because The Respectful > Tool Developers (e.g. (not only) Pharo) in their wisdom find it > necessary to render these obsolete, then this has enormous > consequences: > One would have to edit and test, and in some cases rewrite (!) > very large amounts of coding costing considerable amounts > of time=money. > Now, imagine yourself as an application programmer maintaining > this huge amount of coding, which is not working anymore, > not because you did it wrong, but because of chances in the > Developmen Tool? How would feel? Like shit. Tons of work > gone down the drain. Besides, are you going to ask your > customer to pay for this? You can't of course. He/she will > say things like: "Why? It works perfectly!"etc. > And they are right. Why do you want to change it if it runs perfectly? Why do you want to change it if even your customers don't want to? Thanks to smalltalk as long as you stay in the same image your development tool will stay the same. > Naturally one wishes to migrate to new images releases and > happily utilize the new features that come with it, no question > about it. But as it seems now, this is out of the question, > because with every release, things are taken out, changed > without any respect to backward compatibility. > What is it "naturally" to migrate? Just for the sake of it? Asking for trouble? I think you need a good reasons to migrate. > > I might suggest. for instance: > - leave deprecated classes in. when ever possible! > if you can't, then rewrite them as a sort of emulation > encapsulation, thus a kind of shell, invoking your new > replacement class. > > Why not have the best of both worlds? What's the problem? > Things can live next to each other, if you do it well. > Well, it wouldn't be the best of both worlds. Leaving every cruft in the image will turn it into a mess. There is a legacy problem _and_ a newcomer problem. With collecting cruft you are making it hard for newcomers to be able to work with the image. You as part of the legacy problem are a more experienced developer than a newcomer. Can you imaging how hard it is for a newbie to digest a big pile of code? > If you don't I can only resort to the most basic of > system core classes. Ergo: limit myself to what I am > (reasonable certain of) > > > I see lines on this forum like: > "Seems to be unused. I vote for removing.." > Assuming is a bad thing in software development. > How can you be certain that: > No one really uses the component anymore? > You can't. > > The essence of it all is: > > I saw Pharo fit to write production software, > especially with Seaside! > but how can I use it for this, seen the above > described arguments? If all the things > I write become useless with a next release? > To be honest I cannot share your view. You are willing to benefit from all the new features a new release brings along. At the same time you are reluctant to migrate your software for the changes that came together with this new features. To me it sounds that you are making your life too easy. You have a lot of options in software development. If you have an old system that works just don't change it. There is a whole industry for legacy main frame applications that are kept alive _because_ they just work and there is only risk in changing it. As soon as you change the software you potentially destabilizing it. So upgrading software only for a handful of new features is a high risk if your application is that critical. On the other hand you shouldn't wait for too long to adopt changes in the frameworks you use. Only if you keep for too long the step is huge. You could continously migrate at an easy level. There are intermediate levels between those two extremes and you need to chose one. > > > (Sorry, we don't sell tires for your > car anymore, because we chanced > the diameter of them, we recommend > you to change/modify your car.. ) > Did you every try to get a tire for a 60s car? You don't get these in the usual places! > A perfect example: > (most) internet browsers > are backward compatible. > Yep, and the internet suffered a lot because too many people have tried for too long to be compatible to a shitty browser like IE6. Norbert > I rest my case, enough said.. > > Kind regards > Ted > > > > > > On Mon, May 2, 2011 at 4:03 PM, Igor Stasenko <[email protected]> wrote: >> On 2 May 2011 00:48, Markus Fritsche <[email protected]> wrote: >>> Hi, >>> >>> 2011/4/27 Mariano Martinez Peck <[email protected]>: >>>> And as Marcus said, most of the times (sometimes we had some problems) we >>>> have a deprecation process where we (usually) say which should be used >>>> instead. >>> >>> From a a-little-bit-more-than-user perspective I am looking at >>> >>> SmalltalkImage>>#hasBindingThatBeginsWith: aString >>> self deprecated: 'Use Smalltalk globals'. >>> ^globals hasBindingThatBeginsWith: aString >>> >>> Well, with a bit of analysis, I would be able to figure out, that the >>> author might have intended that I should search the SystemDictionary >>> myself. I feel like an additional comment would have been helpful. >>> >>> Same with the other problem I had with ServiceRegistry - it is gone >>> and it is not easy to find out what that was supposed to do. Next step >>> is to compare squeak and the Pharo releases to find out what happened >>> to it (the issue tracker does not easily yield results for this, but >>> maybe I searched in the wrong way). >>> >>> I know there is no easy fix for this, as "fast deprecation" was what >>> made Pharo manageable compared to other image-based smalltalk dialects >>> (not to mention anything specific ;)) but there is a lot of >>> interesting code on squeaksource that naturally breaks - for those >>> interested in that code, it would be helpful to give a bit more advice >>> on "porting" and "the path of deprecation". >>> >> >> An advice is simple: >> 1. try loading the code using most recent image, try running it. >> 2. fix errors & bugs you found >> 3. Repeat from 1. >> >> This is what package maintainers should usually do all the time. >> And there is no magic: you have to get your hands dirty and make >> things work (again). >> >> Now, if nobody doing it for years, its not a Pharo failure that some >> code turned to be broken. >> I like that pharoers are not afraid to break things (of course if they >> breaking them for good ;). >> >> And besides.. you can always use years old image and happily load all >> code in it and it will work there. >> >> So, you are free to choose either: >> - stay with old image version where all dusty code working >> - running your code on most recent Pharo version and using its new features >> :) >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> >
