[Pharo-users] About "it's not pharo but smalltalk"

TedVanGaalen tedvga at gmail.com
Sat Feb 8 12:02:03 EST 2020


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



More information about the Pharo-users mailing list