Re: Squeak and Pharo: why the fork

On Sat, 16 May 2020 at 16:57, Shaping <[hidden email]> wrote:

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