[Cuis] differences between Cuis and Squeak and Pharo

[Juan Vuletich]

Hi Folks,

Casey comments are right spot on, so I'll add little to them (inline).

On 8/21/2014 6:03 AM, Casey Ransberger wrote:
> Hi David. I'll try to answer as many of your questions to the best of 
> my ability; I will appreciate corrections from others on the list if I 
> get anything wrong.
>
> Inline.
>
> On Aug 20, 2014, at 7:15 AM, Davide Della Casa <davidedc at gmail.com 
> <mailto:davidedc at gmail.com>> wrote:
>
>> Hi,
>>
>> I’m working my way through Cuis code…
>>
>> I start to see some patterns emerging, and it’s clear that design 
>> philosophy is minimal and "clean".
>
> That's the idea, yes:) and to the end that an elegant system lends 
> itself to personal mastery better than a large system with decorations 
> all over it.
>
>> I’ve read the discussions around the class count being kept to a 
>> minimum compared to Squeak and Pharo, and the Morphic 3.0 approach 
>> being about "multi-scale" and best-of-class anti-aliasing solutions, 
>> and the philosophy of keeping the core to a minimum.
>
> That's all consistent with my experience here yes.
>
>> I’m wondering whether there is a more detailed summary of what has 
>> been taken out and refactored and re-architected in respect to Squeak 
>> and Pharo?
>
> First off, don't assume it was all "taken out" by us: in fact many 
> things (e.g. Traits and EToys) were never loaded into Cuis in the 
> first place, as Cuised diverged some time back during Squeak 3.x IIRC. 
> OTOH, Juan has also incorporated a lot of great stuff from Squeak 
> trunk as well. So it's not so straight forward.

The common ancestor of Squeak, Pharo and Cuis is Squeak 3.7. From there, 
each system evolved. I can recall from memory many of the main changes 
done in Cuis since it forked from Squeak 3.7. But to compare with 
current Squeak, I'd need to know in detail how Squeak evolved. I don't 
think doing that is worth it. What I think that makes sense is, when 
studying / working on some specific part of the system, check the 
others, to write cross-fork code, or to import good stuff from them.

In any case, the bigger differences were already told by both of you 
(Davide & Casey).

>> And I mention this because it’s the kind of thing that is difficult 
>> to do for a newbie like me, cause one would need to have some 
>> in-depth knowledge of Squeak and Pharo and Cuis, and yet it would be 
>> really cool to have this map and go “ah I see, this is available just 
>> like in the Squeak examples I’ve seen but I need to plug it from a 
>> package in because the core can do without it…, and look this part is 
>> so much cleaner with two classes I can do what I needed to do with 
>> five”. Also this could be a really useful map for people who would 
>> like to know how to migrate code/packages from one system to Cuis, so 
>> it would be useful well beyond newbies actually…
>
> There isn't a map. Even if such a thing were desirable, I think it 
> would be premature to write that book. Cuis is a planet that hasn't 
> quite cooled yet. It's evolving a lot.
>
> One general rule of thumb might be, you'll have to rewrite most 
> Morphic code from other systems to make it work here. With the rest of 
> the code it depends. "Vanilla" Smalltalk code often cares less which 
> fork it runs on, but stuff with heavy dependencies on parts of 
> Squeak/Pharo which are not absolutely essential to the operation of 
> the system may need heavy porting.

In any case, if you Davide start documenting your experience (relevance 
of examples written for Squeak or Pharo, etc) in, for example, some .md 
documents, we could add them to the GitHub repo, so others could also 
build on top of that. In other words, like everything else in Open 
Source, if it is not there, and it is needed, then just do it.

>> This is *what I know* so far in terms of comparisons by reading online:
>>   - core class count (much lower than other two systems, core kept to 
>> a minimum)
>
> Yep.
>
>>   - morphic 3.0 is scale-agnostic
>
> And is vector-based. That's why it's scale agnostic. And it's coming 
> soon, I think.
>
>>   - rotation of morphs in Cuis is not part of core (is it part of 
>> another package?)
>
> Wrong. It was removed because Squeak's rotation is raster-based, and 
> we're going to do it with vector graphics. See also, Morphic 3.
>
>>   - line morphs in Cuis are plug-in
>
> Not sure about this one off-hand. Juan?

Well, I removed all non-essential morphs, just to make migration to 
Morphic 3 as simple as possible. Ken saw value on some morphs I'd 
removed, so he added them to an optional package. In any case, for 
Morphic 3 we'd build new morphs, closer to SVG concepts.

>>   - layouts in Cuis are minimal (can’t make comparison here, don’t 
>> know enough about the other systems but I know that Squeak needs a 
>> number of other classes)
>
> Yes. One thing I'd like to see us do later is WYSIWYG layout controls 
> from e.g. the halo. But yes, layouts in Cuis have been simplified.

That would be cool to have! In the future, I'd like to make visual 
construction of morphs have the same power as code. That, and some code 
generation would mean having a powerful "visual builder". This is not a 
new idea, Dan Ingalls wanted to do this in the good old Squeak Central days.

>
> Another thing to note is that coordinates in Cuis are relative to the 
> parent morph, not the world. This is also to support a scalable UI.
>
>>   - list of main Cuis packages and repos
>>
>> I wonder whether there are more deltas that can be highlighted… some 
>> come to mind but ideally one would want to have a larger list… for 
>> example I’d love to know:
>>   - approach to naming, are there major classes/methods that are the 
>> same but follow a different naming convention?
>
> Not usually. It's common to see classes with far fewer convenience 
> methods in Cuis. Juan prefers to create new selectors rather than 
> reuse the old ones when the behavior has to change a great deal. Don't 
> quite me on my example because it's from memory, but #position in Cuis 
> became #morphPosition for this reason.
>
> We use the left arrow (underscore) consistently in the core system for 
> assignment, whereas authors of external packages are left to make 
> their own decisions about that.
>
>>   - are all the main morphs still there in the same hierarchy 
>> structure? What are the differences?
>
> Only the most essential Morphs generally are a part of the core of 
> Cuis. The hierarchy of the system is likely to be very similar, with 
> some nodes in the hierarchy removed (e.g. we don't have thirty kinds 
> of buttons or anything like that.)

Yes to all Casey's comments. In addition, I did quite some refactoring 
to honor View / Model separation: Models should not know about Views. 
For instance, class Browser deals with all stuff related with Smalltalk 
code, but it is UI agnostic. It is unaware of the existance of GUIs on 
it. BrowserWindow is the GUI. By contrast, see in Squeak the 
'toolbuilder' category in class Browser.

>>   - is the event system and the re-paint code similar?
>
> Not my department. I think Juan wrote a nice summary of of the 
> differences between the various flavors of Morphic some time back.

Similar but not identical. I did several optimizations. And I haven't 
checked the evolution of that code in Squeak or Pharo since 3.7.

>>   - traits being used or encouraged?
>
> Nope.

(although we won't complain if someone implements them and uses them for 
external packages)

>
>>   - text/fonts, are those the same approach?
>
> The font system in Squeak trunk, last I checked, was from Cuis.

Yes. I did the anti aliased engine and font set used by Cuis and later 
adopted by Squeak and Pharo.

>>   - main tools in the vanilla environment: different/same?
>
> We have less tools in the core than Squeak does (e.g. no dependency 
> browser, etc) but all of the classic ST-80 tools are included.
>
>>   - menus structuring: different/how?
>
> Different? Totally different. How? Partly me:) one concern we have in 
> Cuis is small screens (on general DynaBook principle and because the 
> first two contributors are fond of tiny laptops,) and as such the 
> world menu is much less monolithic.
>
> I also added a bunch of icons to everything. They were from the Tango 
> icon set. One place we could really improve things throughout the user 
> experience is by replacing the Tango icons with some new ones designed 
> to better fit the Smalltalk experience (e.g. currently we have a 
> terminal icon for the workspace, which really isn't appropriate.)

And some day, those icons will look better if SVG.

>>   - other parts that have been taken out completely or put in a package?
>
> I think everything that has been made into a package by Juan is in the 
> Git repository. So you can see that stuff. There isn't a catalogue.
>
> One fun experiment might be to write a workspace expression that makes 
> a dictionary out of the structure of all of the classes in the system, 
> their class and instance methods, their implementations (I'd go with 
> byte code to rule out stuff like assignment, white space) and then 
> compare the resulting dictionaries from the different forks. Because 
> you can do stuff like that !
>
>> Cheers,
>> Davide
>
> Hope I helped a little,
>
> --Casey
>

Please don't hesitate to ask any questions that arise. Or criticize and 
tell about any problems or defects you see. We are open to discussion!

Cheers,
Juan Vuletich
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://jvuletich.org/pipermail/cuis_jvuletich.org/attachments/20140821/655f1009/attachment-0004.html>