On Sat, 16 May 2020 at 16:57, Shaping <shaping@uurda.org <mailto:shaping@uurda.org> > wrote: 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? 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? I'm mainly focused on Pharo but I respect the Squeak heritage and monitor their mail list, chipping in when I can - so I have felt comfortable sharing the general philosophical differences between Squeak and Pharo as I understand them. But as to specifics, you'd probably need someone from Squeak to pair-review the Pharo changelogs [1] with you - and that might not even capture everything. [1] https://github.com/pharo-project/pharo-changelogs But lets also consider something at least as important as all the other points... "resourcing". Assuming all technical and political issues were dealt with, who will do this reintegration work? The work should be distributed amongst those who know the frameworks best, like them and need to use them, and who want one image and the ease it bringsâwhich should be a bunch of people. Or, Iâd have to work with those folks to get up to speed on those frameworks to learn whatâs different, whatâs broken, what can change, what canât change, etc. Doing it all myself even with plenty of consulting seems less efficient. Selfish drivers are important. Community/collective drivers are also important. Balance. Donât leave out the first, or nothing will happen. Assuming You were at a point where you were familiar with both platforms to be capable of doing the work, would You be willing to put aside your other interests to do at least 50% of that work? Probably not for the next year, because of whatâs currently in my queue. Because otherwise discussion around it with the idea that others do it is pointless. :) I see several devs doing the work. One dev probably canât do it. At least one dev should be watching the big picture and presenting results/problems/decision-points. The big picture may not be as big as Iâm thinking. It could be bigger too. I need details. I have one firm detail now: 1. Squeak folks need Tonel. Ergo, port the latest Tonel to the latest Squeak. And two fuzzy details: 1. We need testable criteria to determine how indispensable/always-in-the-image/nonmodular a framework shall be. Itâs an interesting topic. I donât know how itâs currently handled. Development seems organic and wild-west in both camps: if you can get it done on your own time and it provides utility, it can probably get into the main trunk somehow. Is that how it works? 2. Metacello sucks a little for brevity, and Monticello seems to offer some nicer features. And so what do we do here? Fix the Monticello/Metacello frameworks on both sides, or move all to Git? Whatâs wrong with Metacello? Is it too verbose? Can an SME/heavy user defend it and compare it to Monitcello? I want to know what is most valuable about Squeak, and I mean specific features and tools. We can turn either Pharo or Squeak into a world-like Quasi-OS. Thatâs not an argument for greater technical value. It just a mode of use. I can tell you want I like about Squeak (please Squeak folks, add to this), but Iâm almost Squeak-green again after 16 years absence: 1. Flat quick GUIs for development. I just like snap. What can I say. It helps me focus. Iâve sensitive to what I consider to be temporal defects (annoying little pauses). That doesnât mean I like Morphic. I like what I can see and touch, and I like the speed. 2. Debugger is normal (quick). 3. The VM params and stats. I want to work on the VM. I want to do that with nice-looking, quick tools. I thought Pharo would be the best for that. But Squeak seems to be the main tool for VM dev. Note, last year I personally did have the inspiration and intention of investigating the differences between Squeak and the Pharo Bootstrap to understand the possibility of Squeak bootstrapping off the Pharo Bootstrap, so there might one day they might have a common non-gui system - but other interests ended up having a stronger hold on me. Realistically its not something I'll get to any time soon. I too find the common bootstrapping interesting. My personal priority is efficient, thorough parallelization of the VM. I need huge compute-scale, and it has to happen in a dynamic language, the best one. Thatâs going to keep me busy for a while, and I canât even start that for some time (months). Shaping