I am of the side of this argument that Pharo is a kind of Smalltalk, but the group that forked Squeak to create Pharo did so with the express intention of being separate-from-Smalltalk and we should respect that intention. Indeed here we can see three reasons why they feel the need to advertise that separation...
On Fri, 7 Feb 2020 at 21:45, TedVanGaalen <ted...@gmail.com> wrote: > > make improvement/changes only in such > a way that anything written before will > run without any modification You are constraining what Pharo can be. > 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. You are constraining what Pharo can be. > If you want to implement newer core like things > co-existence with previous is preferable. > Do at the very least not alter the core/system classes. You are constraining what Pharo can be. The aim of the advertised statement that Pharo-is-not-Smalltalk is to avoid you "later" being surprised if it differs from ST-80. A marketing strategy analogous to a "fail early" programming paradigm, and avoid such arguments that try to shackle Pharo. In practice, its probably many years before Pharo is any more incompatible with Smalltalk than the incompatibilities between existing Smalltalks. But Smalltalk-backward-compatibility should not be one of your tick-boxes to choose Pharo. cheers -ben
