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

Trygve Reenskaug trygver at ifi.uio.no
Sun Feb 9 07:26:04 EST 2020


+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: trygver at ifi.uio.no <mailto:%20trygver at ifi.uio.no>
Morgedalsvn. 5A http://folk.uio.no/trygver/
N-0378 Oslo http://fullOO.info
Norway                     Tel: (+47) 468 58 625

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-users_lists.pharo.org/attachments/20200209/082fab8c/attachment-0001.html>


More information about the Pharo-users mailing list