On 5/16/20 3:56 AM, Shaping wrote:
Hi Jimmie.
On 5/15/20 5:26 AM, Shaping wrote:
I don’t understand the split. It looks silly. Maybe someone can
explain the split in terms of technical/architectural advantages,
if any exist.
[snip]
The Pink plane community wanted to begin to clean up Squeak. Break it
up into parts which could be reloaded. It wanted a much more modular
environment which allowed you to build the image you want for the
purpose you intend.
The Blue plane community didn't see any problems with the way it was.
They liked it and still do. It fit what they wanted to do with
Squeak/Smalltalk. Frequently more research oriented and less business
oriented.
Applied basic research is most of what I do. I still want a clean,
modular environment. I don’t see how that interferes with creative
verve. It should help if only by limiting confusion and clarifying
configurational choices.
The Squeak and Pharo communities are not unlimited in size and
resources. When you have differing priorities and limited resources, you
have to make choices. Choices you might not rather make. But you make
them anyway. This is what happened. One group had their priorities and
the other theirs. They each split and their respective communities and
resources when the way of their priorities. Most of us did not want a
split. But if one group constrains the other, there becomes no other option.
Then in the midst of all this you have overlap in individuals who
understand both. You also had personality differences and
disagreements which developed over years. Eventually the Pink plane
community forked and created Pharo. The foundational community of
Squeak (Blue plane) did not want to make the changes the Pink plane
community wanted or required.
What are the specific changes that Squeak folks don’t want to make?
Squeak/Pharo is a configurable environment. We can still have a
quasi-OS world if we want that. What specific aspects of the analytic
and creative experience break or degrade for Squeak users with these
specific changes, and also cannot be preserved by loading the right
Smalltalk packages?
This is all true. And most of us do enjoy the quasi-OS world. We want
that. We just don't want to deploy that with our application. Especially
server-side apps who want to run well in a limited environment or an
environment that costs per amount of memory, cpu time, etc.
Pharo is now 12 years or so into its journey. It is not easy losing
weight and still keep working. But that is the goal of Pharo. Keep
reducing until the entire system can be built up from a base image.
And when it gets there. We don't have a problem with from that
foundation, being able to build it back up into a Squeak-like image.
I have numerous projects which I am doing in Pharo. One is a trading
application. I personally want as little in my image as possible which
does not have to do with my trading application. It desires to be as
fast as possible, run without failure, and as memory and cpu efficient
as I can make it to be in Pharo. I could make and run this application
in Squeak. But it would include much that I don't need and don't want.
And that is the case in Pharo currently as well.
This points to needing more modularity, not less. We want to unload
all that we don’t want, in small or big pieces, easily and
confidently, without breaking anything. It sounds easy, but it’s not.
I think this should be one of the Consortium’s main goals.
It is one of the Consortium's goals. However, it take time from highly
skilled, dedicated people. Again, resources are limited. In people,
money and time. So the priorities are directed. We will get there. But
we are not there yet.
But Pharo has its philosophy and its direction that it is moving
towards. At some point in time my trading application will what I want
it to be with very little unused code in the image. That might not be
until Pharo 10+. I don't know. But there is a vision within Pharo for
people to build such applications.
Image minimization is a useful feature. A Squeak user would want
this too, at least when deploying.
Yes, but it is not their priority. They prioritize differently and
within their limited resources.
I have not used Squeak in years. And nothing I write here is meant to
speak badly about Squeak. I like the Squeak community. They are full
of great people. And I do not know how accurate what I write is to the
current Squeak. My apologies for any inaccuracies or errors.
Pharo in general is much more pro-business. It is an explicit goal of
Pharo.
https://pharo.org/about
https://gforge.inria.fr/frs/download.php/30434/PharoVision.pdf
Both websites give you a feel for who the community is and the
orientation of their goals.
As much as re-unification would be nice.
Logical and utilitarian.
I don't know that it will happen. At a minimum, not until the Squeak
community could build Squeak from a Pharo kernel image. Then it would
be possible. But I don't think likely.
What are the specific problems? Anyone?
Resources and the prioritization of them. Personalities within each
community. Branding of each project. As I said. When Pharo reaches its
goal of a kernel image and everything is built from there. The Squeak
community would be more than able to build the next Squeak x.y from
that. Whether of not that happens. Only time will tell. There could be
easily someone from the Pharo communities build the everything is in
there image. It would seem to be a great way to test.
Now had Squeak 15+ years ago had a portion of the funding that Java got.
And had Sun, Google, et al. not chosen Smalltalkers to build HotSpot and
V8 etc, but rather deployed those people and resources to Squeak. We
could be much further down the road. Squeak is open source. They could
have done that. Or if any big corp who spends significant resources on
languages and tools would get a vision for what Smalltalk/Pharo is and
could be. But alas it hasn't happened. So we are each making progress
slowly within the goals and the priorities each have.
Jimmie
