+10
Ted,
I have recently completed a conceptual model with tools for a new way of
programming for novices. It works under Squeak version 3.10.2 and it is
tempting to port it to the current version of Pharo to make it generally
available. This will take time, and the port will probably be outdated
and useless by the time it's finished. I'm 90, so the temptation is
resisted and story ends here.
Best
--Trygve
On 08.02.2020 18:02, TedVanGaalen wrote:
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
--
/The essence of object orientation is that objects collaborateto achieve
a goal. /
Trygve Reenskaug mailto: tryg...@ifi.uio.no <mailto:%20tryg...@ifi.uio.no>
Morgedalsvn. 5A http://folk.uio.no/trygver/
N-0378 Oslo http://fullOO.info
Norway Tel: (+47) 468 58 625
