[Vm-dev] [Pharo-dev] Squeak and Pharo speed differences

[Jakob Reschke]

Hi Shaping,

== First, on the text selection delay issue. ==

Now that you mention it, the text seems to get highlighted slightly
slower than in native Windows widgets or WordPad (which is what I had
available for comparison). But it also behaves differently.

Please try the following and report whether you experience the same
delay: 1) click into the middle of a word with a single click - it
won't get highlighted, 2) click again at the same cursor position -
the whole word should be selected now. Is the reaction to the second
click also too slow? In regular Windows widgets you have to
double-click, not click again, to toggle word selection. Your
experienced delay might therefore be associated with Squeak/Pharo
processing two consecutive single clicks and the OS widgets processing
one proper double click event. But that's only speculation on my part,
I didn't check the code.

== Second, on the divergence of Pharo and Squeak ==
from my perspective and I have not been around at the time of the split yet.

A general note: you will obviously get biased views from each side and
the other one might view them as unfairly presented (which makes such
discussions unproductive quickly). Moreover, much of the divergence is
not in the VM but in the image, so you might not even be talking to
the right people on the Squeak side. Since not everyone is subscribed
to both (or all three) mailing lists, they might not see all the
answers, so you cannot have a coherent discussion at all.

To start with the example, I suppose the new preferences look has
probably not gotten from Pharo into Squeak not because the Squeak
community did not like it, but because it was simply not contributed
back. The Squeak folks would have had to pull it and probably did not
deem it important enough (or were not even aware if they don't use
Pharo regularly). Besides, the preferences in Squeak are also not a
flat list, they have had categories for ages.

If the Squeak community was busy all the time pulling things back from
Pharo, they could not concentrate on their own efforts. I also
understand why the developers of the new Pharo preferences tree did
not like to invest the same effort in Squeak. What incentive would
they have? And here we are. Such differences and the additional effort
are the liability of a fork, for both sides. Some people are or were
active in both communities to invest the effort. For example, Eliot
also provided the image side of VM improvements to Pharo, not only
Squeak, if I remember correctly. I don't know whether he still does
that since the fork of the VM.

Pharo would like to get rid of Morphic; as far as I know, Squeak
embraces Morphic for its direct manipulation interface and UI
discoverability (inspecting Morphs and such). GTK has its inspector,
but I don't know whether you get the same features out of it. Direct
manipulation probably not, only indirect. And can you control that
inspector from Pharo or do you have to write C code to change it in
GTK itself? From my impression, this would be a no-go for Squeak. The
tools must be maintainable in Smalltalk, working with C is a necessary
evil in the VM. Maybe Pharo has found a way to have the best of both
worlds, I don't know.

Still that leaves all Morphic applications behind; their UI (or even
the entire program) would have to be rewritten from scratch. I doubt
that Pharo will keep Morphic workable once they can drop it from the
mainline. And Spec2 is not the first new idea of UI technology in
Pharo, you know. In return, the different technology makes it harder
for Squeak to port new features even if they wanted to, making it less
likely to happen. Even some basic Collection API has changed in Pharo
(string trimming and joining for example), now try to keep your code
compatible with both without messing it up... The compatibility and
porting problems are offloaded to the application and library
developers, even between Pharo releases. I don't know how this can be
advertised as appealing to commercial development. VisualWorks & Co.
could certainly not deal with their users that way.

I don't think that Pharo does bad stuff in general, in fact their work
could be very good (I don't look at it regularly and certainly don't
follow the implementation). Like you said, disentangling,
modularization, test automation, and innovation are valuable goals.
Squeak mostly agrees on the goals, but does not pursue them in the
same disruptive manner. Probably this is the "pushback" you have been
told of...

If Spec is a UI generalization framework that makes it independent
from the graphics implementation, then one should rather compare it to
Squeak's ToolBuilder, not Morphic. ToolBuilder as well could have
different targets, such as GTK, (I have seen Squeak tools rendered
with some Java UI Framework a few months ago) but nobody pushes that
in the Squeak trunk. There was no voiced demand.

I haven't participated in such discussions of the right way™ in the
past, but my impression from what I heard so far is that Pharo pushes
forward rigorously and does not look back, and if it does, then
sometimes with a disparaging or snappy tone. Some of the Squeak guys
are therefore very sceptical about Pharo and their attitude, to say
the least, and sometimes also talk harshly.  The recent fork of the VM
further deepens the trenches, especially since the foundation of
"OpenSmalltalk" VM (no longer "Squeak" VM) was in my perception a
commitment to cooperate at least on that end. There are probably only
a bunch of persons who are responsible for the bad mood, and I assume
that the majority of both communities are in fact friendly people. :-)

Kind regards,
Jakob

Am Sa., 16. Mai 2020 um 08:40 Uhr schrieb Shaping <shaping at uurda.org>:
>
>
>
> 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."
>
>
>
> Lol  Thanks for the explanation.  That’s more or less what I thought.
>
>
>
> But can’t the differences be setup at config-your-environ time instead of build time, when the task is heavier and slower?
>
>
>
> 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.
>
>
>
> I like disentangling and modularizing.   I suppose this is a universal like.
>
>
>
>   They also wanted to move to a reproducible-build-system where each change "bootstrapped" a nightly image from an empty file,
>
>
>
> I like this too.
>
>
>
> whereas Squeak continues to use a "continuous evolution" model.
>
>
>
> Don’t both groups want the automatic building and testing the Consortium is talking about recently?
>
>
>
> I’m not sure I understand how “continuous evolution” works.  Sounds like there is lots of wiggle room in that idea.  Don’t we need some structure?  We seem to be getting that in Pharo.
>
>
>
> I’m not sure about Squeak.  The GUI tools/menus still feel hodgepodge (much nicer, but still not well organized) 16 years later.  I used it between 2002 to 2004, and then again just a few days ago.  I like the faster debugger and the flat GUIs, but I don’t need Morphic to have those dev-tool GUIs.  I’d prefer to rework the GUIs with Spec2/GTK3, and keep the flat, clean, button-packed look with some improvements (like the new Spec2 selection highlighting pattern, which is very nice).  The rest of Squeak seems messy.
>
>
>
> I do very much like the technical, concrete feel of Squeak’s details about the VM.  That reminds me of old times and why I got involved in computers, and it supports my current interest in VM parallelization.  Those VM details need a somewhat different shape/presentation.  There is a beauty in Squeak, but the eviron still feels a bit rough.
>
>
>
> For example, why aren’t all those preferences in a tree where you can actually find things because they are categorized.  It’s a big list.  That seems very strange in 2020.  Why don’t Squeak folks borrow the Pharo Settings GUI idea, and implement that in Morphic, as they like?  I thought more would have happened in the Squeak GUI in 16 years, but I’ve not seen all of 5.3 yet.  I’m still poking around.  I suppose most of the improvements are in the VM, which I imagine absorbs most of the group’s energy.
>
>
>
> 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
>
>
>
> Thank you.  I will read it.   Is the Consortium updating that doc?  There was a doc recently from Stef that looks like it belongs in there, merged somehow.
>
>
>
> 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.
>
>
>
> Agreed.  I don’t understand the pushback because I don’t understand Squeak folks’ objection to rigorous, systematic, automatic testing and disentangling/modularizing of frameworks.  They are probably fine with all that.  Do Squeak folks have a document that defines “continuous development.”  I know that VM testing is automated.  I don’t see how the objectives are so different, at least on the automation front.  Everyone seems to agree that CI is good.
>
>
>
>
>
>  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.
>
>
>
> I never liked the halo thing.  It’s okay.  It seemed/seems too busy and distracting.  I think Morphic and the “too many cooks” problem is why I broke off in 2004.
>
>
>
> If we are fully modular, and you love Morphic, and want to live there mentally and visually, all the time, then load the Morphic package into the new universal OpenSmalltalk.  Have all your GUIs built with Morphic.  Have cute little morphs stuck here and there.  Knock yourself out.  Don’t like Morphic?  Don’t think it’s cute?  Load the more business-like-but-not-boring Spec2.  I don’t see an insurmountable technical problem here.
>
>
>
>
>
> 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.
>
>
>
> Yes, the Spec2 Launcher is inspiringly snappy, modulo the text-selection slowness problem, which is everywhere in Pharo and Squeak.  I’ve mentioned this a few times recently—of all the goofy things to prevent a port from VW…..Okay, that and Pharo’s slow debugger.  Two things keep me out of Pharo/Squeak.  I don’t love VW.   I tolerate it really well.  That’s different.  J
>
>
>
> 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.
>
>
>
> I agree with the objective.
>
>
>
> This conflicts with Squeak's backward comparability goals.
>
>
>
> Okay, this is the real problem.
>
>
>
> So there is a ton of old Squeak code that no one is willing to rework in order to be compatible with the new vision for native-windowing independence.  Perhaps someone can give more details on that old code.
>
> I suppose many Squeak folks bemoan all the extra work needed for a recoding.  Is this still really an issue?  Maybe very little of that old code is still being used in business-critical ways.  The need for a recoding may not be the big issue it once was.
>
>
>
> 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.
>
>
>
> That’s a very good idea.  Why don’t all the Squeak folks work on it?  Are you the only one pushing for this?
>
>
>
>
>
>  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 (??)
>
>
>
> It’s a good question.  Is the core Morphic issue whether GTK3 can render non-rectangular shapes efficiently?  There’s a lot of that in Morphic.  I suppose it’s the main concern.  Even if Morphic relies on special drawing primitives, they can go in a lib and be accessed via FFI.
>
>
>
> Shaping