On Fri, 15 May 2020 at 14:09, Shaping <shap...@uurda.org> wrote: > Why can’t the OSVM be a single, unforked, maxed-out VM with all the best > and fastest features working in Squeak and Pharo? *Why did the split > happen?* >
In very general terms, the fork was due to their being Group A wanting to go one direction and Group B wanting to go in a different direction. i.e.... B says "We want to do X". A says "We don't want to do X." B says "We really want to do X." A says "Definitely no." B says "We really want to do X and actually we're doing it over here." In essence, Squeak considered backward compatibility of prime importance including the code of some applications that had become entangled in the main code base. Pharo wanted to "clean the code" by disentangling and stripping those parts. They also wanted to move to a reproducible-build-system where each change "bootstrapped" a nightly image from an empty file, whereas Squeak continues to use a "continuous evolution" model. And there are more reasons I probably not aware of. Here is the Pharo Vision document circa 2012 which inspired me https://hal.inria.fr/hal-01879346/document It looks like a bad use of energy in a community that is small and needs to > use its human resources efficiently. > Trying to go one way and dealing with continual pushback and conflict around that is also bad energy. I want to help, but need to port first from VW, and I’m trying to choose > Squeak or Pharo. Both have speed problems. Squeak has fewer, but Pharo > could be much faster with broad use of Spec2. > > > *Would reintegrating Squeak and Pharo development make more sense?* > I think that is not likely. Both continue to have different goals. And a significant area where they are likely to continue to diverge is the graphics. Squeak is likely(?) to stay with Morphic a long while Pharo intends to dump Morphic. This is one of the reasons that Spec was created - to be independence layer. IIUC in Pharo 9 Spec is already working on top of a GTK3 backend. wrt the VM, Pharo want to remove all native-windowing from the VM, so that window opening is controlled from the Image via FFI rather than the VM. This conflicts with Squeak's backward comparability goals. This change would effectively create more devs willing to work on any > problem. This change would also prevent fracturing of feature-sets across > the two Smalltalks from happening in the first place. > I personally had the inspiration that Squeak might be based off the Pharo Headless Bootstrap, but in the end I didn't find the time to push this further. Squeak and Pharo GUI styles are different. So be it. Can’t the GUI > frameworks and conventions be separated in the same image, and configured > as desired in GUI sections of Settings? > Pharo currently can use both Morphic and GTK3 for its GUI backend. Possibly the GTK3 backend would provide some speed benefit (??) cheers -ben
