[squeak-dev] Re: Why Cuis?

Andreas Raab andreas.raab at gmx.de
Sun Aug 22 22:21:04 UTC 2010


On 8/22/2010 2:28 PM, Casey Ransberger wrote:
> To be clear: I am not arguing against rebasing the trunk on Cuis. I'm just not clear on what we gain by doing so, rather than by continuing to make packages unloadable, and by settling on a mechanism to reload them on demand, while keeping reasonable safeguards in place to make sure they'll work with a particular release.
>
> Andreas, Juan? Care to comment?

"Rebasing" is not the goal here. I apologize if that impression was 
made, but it's not how I think about this. The goal is to learn whatever 
we can from Cuis or any other system in terms of where the modularity 
boundaries are, and how we need to restructure Squeak to achieve a 
similar level of modularity.

I think what we'll learn is that there "themes" where a particular 
pattern or concern is repeatedly applied or addressed, and it is by 
identifying such themes that I think we can make real progress. This is 
why I am interested in the analysis - I would expect that the sets of 
modifications fall into such themes that can be applied in the context 
of Squeak.

In the end, the result might be so similar as to be indistinguishable, 
but that would be the end result of a series of steps applied to Squeak. 
Steps, which I might add, that are there to ensure that we do these as 
an actual refactoring [1] instead of vandalizing the code base that 
utilizes it.

[1] http://en.wikipedia.org/wiki/Refactoring
Code refactoring is the process of changing a computer program's source 
code *without* modifying its external functional behavior in order to 
improve some of the nonfunctional attributes of the software. (emphasis 
mine)

Cheers,
   - Andreas

> I appreciate that Cuis really does keep with the spirit of ST-80, whereas Squeak has seen some design drift in it's use as a research environment.
>
> My biggest concern is: has Cuis seen the same scrutiny that went into Squeak 4.0 with regard to licensing concerns? Have we run this idea past the SFC?
>
> One thing that I do think might be interesting: what might we learn by merging with a fork? I'd hope we might learn a lot about merging forks in. Could come in handy when it comes time to (hopefully) rebase Etoys on Squeak; possibly other things.
>
> In any event, you will have my support to the extent that I'm able to be of service.
>
>
>




More information about the Squeak-dev mailing list