Smalltalk › Pharo › Pharo Smalltalk Users

About "it's not pharo but smalltalk"

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

55 messages Options

123

horrido

Re: About "it's not pharo but smalltalk"

> The whole reason Pharo exists is to break free from the constraints of
other people's ideas of what Smalltalk is and should remain to be.

Pharo is no more constrained by Smalltalk's legacy than GNU Smalltalk (which
eschews the traditional IDE) and Hoot Smalltalk (a JVM-based Smalltalk with
unique enhancements) and Dolphin Smalltalk (which dares to be Windows-only)
are.

Most Smalltalks have their own special enhancements thus making them less
and less compatible with "standard" Smalltalk.

So I see no reason to worry about Pharo being shackled. I always advertise
Pharo as "a modern variant of Smalltalk created in 2008" which should cement
the idea that Pharo is relevant today. I always compare Pharo to Clojure (a
modern variant of LISP) and Elixir (a modern variant of Erlang).

Pharo is free to make great strides forward. As long as its "core" remains
Smalltalk, Pharo will always be a Smalltalk. No matter how much Pharo
evolves, it will never give up its core, which includes:

1. Alan Kay's pure and simple object-oriented conception.

2. The core syntax which is message-based and consists of three types of
messages.

3. The live coding environment.

4. Reflectivity and a powerful metaprogramming capability.

I can't imagine a future where Pharo wouldn't have these defining qualities.
Therefore, Pharo belongs in the Smalltalk family.

And, btw, Sven, you are absolutely correct: Pharo is not Smalltalk. Because
Smalltalk is not one language but a family of languages. No one thing can be
a family.

However, Pharo is a Smalltalk. And this is undeniable.

--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

philippeback

Re: About "it's not pharo but smalltalk"

This is tiring.

I like reading those blog posts.

And Pharo is not exactly Smalltalk, so what? Syntax close enough, principles close enough.

What is there to win in arguing about this point?

I have been not using Pharo for a while commercially, because, well, Pharo is a hard sell to companies.

Hence doing Scala, Java, and other "less productive" environments.

But with Eclipse Collections, Java 8 feels quite close when coupled with something like IntelliJ Ultimate.

From where I stand this looks like a battle in kindergarten.

Yawn.

Phil

ᐧ

On Thu, Feb 6, 2020 at 4:52 PM horrido <[hidden email]> wrote:

> The whole reason Pharo exists is to break free from the constraints of
other people's ideas of what Smalltalk is and should remain to be.

Pharo is no more constrained by Smalltalk's legacy than GNU Smalltalk (which
eschews the traditional IDE) and Hoot Smalltalk (a JVM-based Smalltalk with
unique enhancements) and Dolphin Smalltalk (which dares to be Windows-only)
are.

Most Smalltalks have their own special enhancements thus making them less
and less compatible with "standard" Smalltalk.

So I see no reason to worry about Pharo being shackled. I always advertise
Pharo as "a modern variant of Smalltalk created in 2008" which should cement
the idea that Pharo is relevant today. I always compare Pharo to Clojure (a
modern variant of LISP) and Elixir (a modern variant of Erlang).

Pharo is free to make great strides forward. As long as its "core" remains
Smalltalk, Pharo will always be a Smalltalk. No matter how much Pharo
evolves, it will never give up its core, which includes:

1. Alan Kay's pure and simple object-oriented conception.

2. The core syntax which is message-based and consists of three types of
messages.

3. The live coding environment.

4. Reflectivity and a powerful metaprogramming capability.

I can't imagine a future where Pharo wouldn't have these defining qualities.
Therefore, Pharo belongs in the Smalltalk family.

And, btw, Sven, you are absolutely correct: Pharo is not Smalltalk. Because
Smalltalk is not one language but a family of languages. No one thing can be
a family.

However, Pharo is a Smalltalk. And this is undeniable.

--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

horrido

Re: About "it's not pharo but smalltalk"

In reply to this post by NorbertHartl

> You can evangelize what you want but I would prefer if you have to
evangelize, keep it to smalltalk and do not refer to pharo, not even with
screenshots.

Whoa! You want me to remove all references to Pharo in my
smalltalk.tech.blog???

That would eliminate most of the current blog posts. It would hollow out the
Resources page. And like I intimated before, it would utterly destroy my
JRMPC competition.

There would be no point in evangelizing Smalltalk anymore. Your position is
completely unreasonable. I'll go further and say it's insane. I hope most
Pharoers are not so extreme.

--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Sean P. DeNigris

Re: About "it's not pharo but smalltalk"

Administrator

In reply to this post by TedVanGaalen

> pharo is not smalltalk
> TedVanGaalen wrote
>> Pharo IS Smalltalk, whether you like it or not.

An ancient parable goes...

> A group of blind men heard that a strange animal, called an elephant, had
> been brought to the town, but none of them were aware of its shape and
> form. Out of curiosity, they said: "We must inspect and know it by touch,
> of which we are capable". So, they sought it out, and when they found it
> they groped about it. In the case of the first person, whose hand landed
> on the trunk, said "This being is like a thick snake". For another one
> whose hand reached its ear, it seemed like a kind of fan. As for another
> person, whose hand was upon its leg, said, the elephant is a pillar like a
> tree-trunk. The blind man who placed his hand upon its side said the
> elephant, "is a wall". Another who felt its tail, described it as a rope.
> The last felt its tusk, stating the elephant is that which is hard, smooth
> and like a spear.

And from its Wikipedia article:

> In some versions, they stop talking, start listening and collaborate to
> "see" the full elephant.

TL;DR

Two parts of the same elephant:
1. Pharo is Smalltalk (in the sense that St-72, 76, and 80 are)
2. Pharo is not Smalltalk (in the sense that most non-Smalltalkers think
that "Smalltalk" = St-80, so they would be mislead and unnecessary turned
off by #1)

The *marketing* decision's logic is something like the following: Given that
both of these soundbites are equally (un)true, which one is more likely to
bring people to Pharo?

|-----------------|-------------Audience--------------------|
|--Sound Byte--|--Familiar w ST--|------Unfamiliar------|
____________________________________________|
|--Pharo = ST---|-----N/A*-------| Ew! Last century!----|
|-Pharo ~= ST--|-----N/A*-------| Hmm, interesting...--|
* Have already made up their mind and will not likely be convinced by a
soundbite anyway

While one can certainly understand disagreeing with the possible
effectiveness of the strategy, these threads usually IMHO have the feel of a
holy war from the camp touching the "Pharo = ST" part of the elephant.

In the unlikely event that anyone is still reading this, I'll paste my
longer explanation from a similar 2015 thread [1]

Sean P. DeNigris wrote

> The best way to understand the rationale for Pharo's marketing decision is
> to read one of the many long threads about it on the Pharo lists. I doubt
> rehashing it will provide new value.
>
> The issue boils down to the fact that the term Smalltalk has been
> overloaded. The original meaning was prototype Dynabook software that was
> used to bootstrap its replacement every 4 years. This true definition, by
> design, leaves plenty of room for innovation. Unfortunately, when
> Smalltalk-80 was released to the world, that became what people mean when
> they use the word Smalltalk. Obviously, people already familiar with
> Smalltalk are going to look at Pharo and go, "oh look, it's Smalltalk"*.
> But that is not the target market. The audience for the Smalltalk-inspired
> campaign is the other 99% of programmers who would never get past:
> "Smalltalk = 1980 = dead = not worth checking out".
>
> Anyway, I'd rather get back to hacking than waste more time in these IMHO
> mostly-pointless debates. In fact, I disagree that unpopularity is a
> problem at all. I would say that our biggest advantage is not being
> popular. I'll take a small community of true-believers over a mob of trend
> followers any day.
>
> * Although they'd probably base that opinion on the syntax, which is the
> least important part of Smalltalk (the live environment being first, and
> libraries second). In fact, if Ruby had a live, dynamic,
> turtles-all-the-way-down environment, with a Morphic-like uniform, live
> interface, and Smalltalk-like tools, I probably wouldn't have gravitated
> to Smalltalk

1. Why Aren't People Using Smalltalk?
http://forum.world.st/Why-Aren-t-People-Using-Smalltalk-tp4843473p4848195.html

-----
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Cheers,
Sean

Lorenzo

R: About "it's not pharo but smalltalk"

In reply to this post by philippeback

Bravo!!!!!

Lorenzo

Da: Pharo-users [mailto:[hidden email]] Per conto di [hidden email]
Inviato: giovedì 6 febbraio 2020 19:41
A: Any question about pharo is welcome <[hidden email]>
Oggetto: Re: [Pharo-users] About "it's not pharo but smalltalk"

This is tiring.

I like reading those blog posts.

And Pharo is not exactly Smalltalk, so what? Syntax close enough, principles close enough.

What is there to win in arguing about this point?

I have been not using Pharo for a while commercially, because, well, Pharo is a hard sell to companies.

Hence doing Scala, Java, and other "less productive" environments.

But with Eclipse Collections, Java 8 feels quite close when coupled with something like IntelliJ Ultimate.

From where I stand this looks like a battle in kindergarten.

Yawn.

Phil

Immagine rimossa dal mittente. ᐧ

On Thu, Feb 6, 2020 at 4:52 PM horrido <[hidden email]> wrote:

> The whole reason Pharo exists is to break free from the constraints of
other people's ideas of what Smalltalk is and should remain to be.

Pharo is no more constrained by Smalltalk's legacy than GNU Smalltalk (which
eschews the traditional IDE) and Hoot Smalltalk (a JVM-based Smalltalk with
unique enhancements) and Dolphin Smalltalk (which dares to be Windows-only)
are.

Most Smalltalks have their own special enhancements thus making them less
and less compatible with "standard" Smalltalk.

So I see no reason to worry about Pharo being shackled. I always advertise
Pharo as "a modern variant of Smalltalk created in 2008" which should cement
the idea that Pharo is relevant today. I always compare Pharo to Clojure (a
modern variant of LISP) and Elixir (a modern variant of Erlang).

Pharo is free to make great strides forward. As long as its "core" remains
Smalltalk, Pharo will always be a Smalltalk. No matter how much Pharo
evolves, it will never give up its core, which includes:

1. Alan Kay's pure and simple object-oriented conception.

2. The core syntax which is message-based and consists of three types of
messages.

3. The live coding environment.

4. Reflectivity and a powerful metaprogramming capability.

I can't imagine a future where Pharo wouldn't have these defining qualities.
Therefore, Pharo belongs in the Smalltalk family.

And, btw, Sven, you are absolutely correct: Pharo is not Smalltalk. Because
Smalltalk is not one language but a family of languages. No one thing can be
a family.

However, Pharo is a Smalltalk. And this is undeniable.

--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

TedVanGaalen

Re: About "it's not pharo but smalltalk"

In reply to this post by TedVanGaalen

Although I'll stick to what I wrote,
looking back at what I wrote, it appears as to be
not friendly at all times, I will try to prevent that next time.
It also has to do with communication in writing only, which
is a whole lot different as talking and listening while e.g.
sharing a table together and discuss things e.g. during a coffee break..
and some laughter at times.

What I still kindly suggest:
make improvement/changes only in such
a way that anything written before will
run without any modification, which in fact
also means: do not deprecate things!

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.
This is probably the biggest curse in
software development these days.

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.

It is probably also the maximum level where
standardization in Smalltalk is possible, nevertheless..
This attitude then could open up the possibility for minimal
standardization for core/system classes. Solely on that level.
On top of that everybody can build whatever they want.

In any aspect in industry the awareness that standardization
is a necessity is beyond any doubt, alas, not in software
development. One of the reasons aeroplanes are falling
from the sky, elections go wrong and so on.

For those not aware about the importance of standardization:
read this:
https://en.wikipedia.org/wiki/Standardization

Regards
TedvG

--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

TedVanGaalen

Re: About "it's not pharo but smalltalk"

In reply to this post by TedVanGaalen

horrido

Re: About "it's not pharo but smalltalk"

In reply to this post by Sean P. DeNigris

> The audience for the Smalltalk-inspired campaign is the other 99% of
programmers who would never get past: "Smalltalk = 1980 = dead = not worth
checking out".

Never? This is what I've been trying to overcome for the past 5 years with
hundreds of blogs.

> Have already made up their mind and will not likely be convinced by a
> soundbite anyway

Agreed. However, hundreds of blogs over 5 years is much more than a
"soundbite."

I agree that Pharo's current "marketing" strategy is working, if by working
you mean slow but steady growth. It may never become as "popular" as, say,
Kotlin or Rust.

I have a greater ambition for Smalltalk: to restore its popularity from 25
years ago. Or even from just 7 years ago when it was #37 at TIOBE
<https://web.archive.org/web/20121215020045/http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html>
. (Sadly, today it's not even in the Top 50.)

I *believe* Smalltalk can have a bright future. Unfortunately, few people
share this sentiment.

https://youtu.be/BS_gLFOrjMw

Sean P. DeNigris wrote

>> pharo is not smalltalk
>> TedVanGaalen wrote
>>> Pharo IS Smalltalk, whether you like it or not.
>
> An ancient parable goes...
>
>> A group of blind men heard that a strange animal, called an elephant, had
>> been brought to the town, but none of them were aware of its shape and
>> form. Out of curiosity, they said: "We must inspect and know it by touch,
>> of which we are capable". So, they sought it out, and when they found it
>> they groped about it. In the case of the first person, whose hand landed
>> on the trunk, said "This being is like a thick snake". For another one
>> whose hand reached its ear, it seemed like a kind of fan. As for another
>> person, whose hand was upon its leg, said, the elephant is a pillar like
>> a
>> tree-trunk. The blind man who placed his hand upon its side said the
>> elephant, "is a wall". Another who felt its tail, described it as a rope.
>> The last felt its tusk, stating the elephant is that which is hard,
>> smooth
>> and like a spear.
>
> And from its Wikipedia article:
>
>> In some versions, they stop talking, start listening and collaborate to
>> "see" the full elephant.
>
> TL;DR
>
> Two parts of the same elephant:
> 1. Pharo is Smalltalk (in the sense that St-72, 76, and 80 are)
> 2. Pharo is not Smalltalk (in the sense that most non-Smalltalkers think
> that "Smalltalk" = St-80, so they would be mislead and unnecessary turned
> off by #1)
>
> The *marketing* decision's logic is something like the following: Given
> that
> both of these soundbites are equally (un)true, which one is more likely to
> bring people to Pharo?
>
> |-----------------|-------------Audience--------------------|
> |--Sound Byte--|--Familiar w ST--|------Unfamiliar------|
> ____________________________________________|
> |--Pharo = ST---|-----N/A*-------| Ew! Last century!----|
> |-Pharo ~= ST--|-----N/A*-------| Hmm, interesting...--|
> * Have already made up their mind and will not likely be convinced by a
> soundbite anyway
>
> While one can certainly understand disagreeing with the possible
> effectiveness of the strategy, these threads usually IMHO have the feel of
> a
> holy war from the camp touching the "Pharo = ST" part of the elephant.
>
> In the unlikely event that anyone is still reading this, I'll paste my
> longer explanation from a similar 2015 thread [1]
>
> Sean P. DeNigris wrote
>> The best way to understand the rationale for Pharo's marketing decision
>> is
>> to read one of the many long threads about it on the Pharo lists. I doubt
>> rehashing it will provide new value.
>>
>> The issue boils down to the fact that the term Smalltalk has been
>> overloaded. The original meaning was prototype Dynabook software that was
>> used to bootstrap its replacement every 4 years. This true definition, by
>> design, leaves plenty of room for innovation. Unfortunately, when
>> Smalltalk-80 was released to the world, that became what people mean when
>> they use the word Smalltalk. Obviously, people already familiar with
>> Smalltalk are going to look at Pharo and go, "oh look, it's Smalltalk"*.
>> But that is not the target market. The audience for the
>> Smalltalk-inspired
>> campaign is the other 99% of programmers who would never get past:
>> "Smalltalk = 1980 = dead = not worth checking out".
>>
>> Anyway, I'd rather get back to hacking than waste more time in these IMHO
>> mostly-pointless debates. In fact, I disagree that unpopularity is a
>> problem at all. I would say that our biggest advantage is not being
>> popular. I'll take a small community of true-believers over a mob of
>> trend
>> followers any day.
>>
>> * Although they'd probably base that opinion on the syntax, which is the
>> least important part of Smalltalk (the live environment being first, and
>> libraries second). In fact, if Ruby had a live, dynamic,
>> turtles-all-the-way-down environment, with a Morphic-like uniform, live
>> interface, and Smalltalk-like tools, I probably wouldn't have gravitated
>> to Smalltalk
>
> 1. Why Aren't People Using Smalltalk?
> http://forum.world.st/Why-Aren-t-People-Using-Smalltalk-tp4843473p4848195.html
>
>
>
> -----
> Cheers,
> Sean
> --
> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Ben Coman

Re: About "it's not pharo but smalltalk"

In reply to this post by TedVanGaalen

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 <[hidden email]> 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

Pharo Smalltalk Users mailing list

Re: About "it's not pharo but smalltalk"

Smalltalk didn't "fail". We just didn't have the CPU power at the time
to achieve our dreams! And "Smalltalk is slow" was tagged forever
besides the name...

2020-02-08 07:17, Ben Coman wrote: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
>

--
-----------------
Benoît St-Jean
Yahoo! Messenger: bstjean
Twitter: @BenLeChialeux
Pinterest: benoitstjean
Instagram: Chef_Benito
IRC: lamneth
GitHub: bstjean
Blogue: endormitoire.wordpress.com
"A standpoint is an intellectual horizon of radius zero". (A. Einstein)

horrido

Re: About "it's not pharo but smalltalk"

In reply to this post by Ben Coman

I agree completely. Pharo is a Smalltalk, but it need not be constrained by
Smalltalk-80. Pharo is completely free to chart its own course. As far as I
can tell, Nik Boyd's Hoot Smalltalk is doing the same thing.

This is purely a PR matter. Pharo's reputation doesn't want to be tarred
with Smalltalk's feathers. So the philosophy is, sever all ties with
Smalltalk's legacy.

Well, that's one approach. Here's another: change the public's perception of
Smalltalk. Take the bull by the horns. That's the total premise of my
five-year PR campaign.

Smalltalk's legacy is not an albatross. It can be a source of great power
for publicity. I intend to prove that.

Ben Coman wrote
> 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 <

> tedvga@

> > 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

--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

TedVanGaalen

Re: About "it's not pharo but smalltalk"

In reply to this post by Ben Coman

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

Trygve

Re: About "it's not pharo but smalltalk"

+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 collaborate to achieve a goal.
Trygve Reenskaug      [hidden email]
Morgedalsvn. 5A       http://folk.uio.no/trygver/
N-0378 Oslo             http://fullOO.info
Norway                     Tel: (+47) 468 58 625

Sean P. DeNigris

Re: About "it's not pharo but smalltalk"

Administrator

Trygve Reenskaug wrote
> I have recently completed a conceptual model with tools for a new way of
> programming for novices.

Hi trygve, what is the project and how can I install it? I try to follow all
your work...

Trygve Reenskaug wrote
> the port will probably be outdated
> and useless by the time it's finished.

I wouldn't say that's true in my experience updating projects from Pharo 1.x
-> 8.0.1 as each version came out. While it can be difficult to do a big
jump, porting from one to the next has usually been fairly straightforward.
So if you did port it (and maybe I can help), it shouldn't be too
outdated/hard-to-maintain. That said, a Morphic replacement has been on the
burner for quite a while and I assume there's a heavy graphical component,
so that would have to be redone. However, this is a problem *everyone* will
face together so I am sure there will be plenty of support...

-----
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Cheers,
Sean

Sean P. DeNigris

Re: About "it's not pharo but smalltalk"

Administrator

In reply to this post by TedVanGaalen

TedVanGaalen wrote
> I am only suggesting that Pharo should be downward compatible
> (that is, within Pharo's scope only).

I agree that this is a worthy ideal, but IMHO is not realistic with the
current resources (time and staff). All that additional code would have to
be maintained. In the worst case, entire subsystems would have to remain in
the image - we changed to Calypso browser but Nautilus would still have to
lurk around in case someone hooked in. For limited cases, there could be a
compatibility layer, but again, we are struggling to implement our top
priority dreams, and don't have the luxury of extra resources available for
worthy but lower-priority things like this. Of course anyone - or group -
for which this is a higher priority, could do just that. It would be like
Grease, but for Ph2Ph I guess...

-----
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Cheers,
Sean

123