Squeak and Pharo why the fork

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.

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.

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