Hi Ben Maybe you misunderstood what I meant. I was thinking of Pharo-backward-compatibility. not Smalltalk-backward-compatibility
I am only suggesting that Pharo should be downward compatible (that is, within Pharo's scope only). meaning that everything built wit Pharo version X should load and run in Pharo pharo version X + n without any changes. This means that a package/app running OK in Pharo 8, should work without any changes whatsoever in, say, Pharo 12, ca 2 years later. and even beyond that, preferably many Pharo releases later! Therefore, any extension/improvement of Pharo itself should be done on top of that, not by replacing/deprecating existing classes. As not to break downward compatibility. (looking at the basic underlying system classes, it looks like this has already been done that way in most cases, simply because Smalltalk is a hierarchical rooted object system, which means that changing the deeper is very hard because it (could) tears up the very fabric of Smalltalk/Pharo itself, right?) If one reads through this Pharo user forum, and also many other Smalltalk forums, you can read about many cases of packages that no longer will work after yet another version of Pharo is released. This is unacceptable: new Pharo releases should not break those packages. read again: > Downward compatibility prevents people > from have tediously edit and test their packages > again and again each time some have > the "brilliant" idea to deprecate stuff. Let's assume for a moment that I want (currently i don't) to create a package/application, taking many months of my precious time. After a long time, my hard work is finally completed and tested: wow, the big dragon flies! However, yet another year later, it no longer loads and I have to spend a considerable amount of time re-editing and testing my package to get it working correctly again, let alone thereby considering the delicate interaction with other third party packages that -guess what?- are dealing with similar release breaking problems at the same time. Unnecessary work, repeating itself with almost every new version of Pharo. Realizing that this is an almost eternal trap, this suffices to deter me from even starting to create such a package! Thus trying to avoid a very tedious and iterating process of repairing things that once were perfectly OK. Somehow many don't seem get this: Too academic? making some sort of hobby out of their work. without realizing real-world situations in a though production/industrial environment. In combination with the lack of standardization of Smalltalk, this is probably one the reasons the installed base of Smalltalk (and Pharo based apps) is very small. If one doesn't understand this, one should ask themselves why the heck they are software developers in the first place. On IBM mainframes I can still load and recompile unchanged COBOL source files from ca. 1974 and they'll run flawlessly: more than 40 years later. (btw your bank account runs on mainframes, probably in COBOL btw.) Of course it is a splendid idea to improve Pharo, seeing how Pharo is now, great to work with. However, this should be done in such a way that downward compatibility is guaranteed. IMHO, Regards TedvG. -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html
