Squeak is an unsuccessful open source project (was RE: Let us face reality)

stéphane ducasse ducasse at iam.unibe.ch
Tue Feb 1 09:36:43 UTC 2005


> yes! one note/question - do you think using Stef's (at all) Traits 
> would

Nathanael's traits (I'm only responsible of the topic and aliases :)
But yes this is the goal of traits.

> replace the need for interfaces and/or delegation or do you see 
> something
> inheritent in having interfaces that Traits would not cover (because I 
> assume
> Trait's provide what delegation can give us). [Well in any case it's 
> time for
> me to start playing with Traits, loaded the new version this wekk but 
> not
> time ...]
>
> Milan
>
>
>
> On January 30, 2005 09:52 am, Trygve Reenskaug wrote:
>> Hear, hear!
>>
>> Subclassing is generally evil with two exceptions:
>> 1) When subclassing a stable core.
>>     The only way for core classes to evolve is by creating
>>     new classes with new names.
>> 2) When a developer creates super- and subclass simultaneously.
>>
>> The Squeak programming environment needs to be extended with support
>> for  Interfaces. A great deal of what we today do with subclassing 
>> should
>> be done with delegation.
>>
>> Finally, the notion of a Component as an object that encapsulates 
>> other
>> objects looks promising for program sharing; more robust than the code
>> based Package.
>>
>> Cheers
>> --Trygve
>>
>> At 11:20 30.01.2005, Peter wrote:
>>> [...]
>>> -- another way --
>>>
>>> 1. Throw away the notion that you can depend on that big, juicy class
>>> library.  You can't, and it's a mistake to try, because it will 
>>> evolve
>>> faster than you can keep up and your code will rot.
>>>
>>> 2. Decide on a very small, stable core.  Collection and number 
>>> classes may
>>> be a good start.
>>>
>>> 3. Introduce a proper notion of interfaces for these.  Freeze the
>>> interfaces, either formally or by people avoiding modifying them.
>>>
>>> 4. Build up from this core.  In each package - for example, the MVC 
>>> UI -
>>> define and freeze interfaces.  Document all the dependencies.  
>>> Ensure each
>>> package can be loaded into an image that only has its dependencies 
>>> loaded;
>>> and ensure that a package *cannot* alter any other package.  Yes, 
>>> this
>>> means that nobody except the maintainer of the core can touch 
>>> Object, for
>>> any reason, no matter how apparently noble.
>>>
>>> We will then have a basis for a system that might begin to satisfy 
>>> (2)
>>> above.  (1) will only happen when another (non-SqC) group of people 
>>> get
>>> together and decide to use Squeak for a project.  The larger 
>>> community
>>> cannot force it.
>>>
>>> Note that by making a system that is suitable for parallel 
>>> development by
>>> many developers, we have thrown away most of the things that make 
>>> Squeak
>>> such a productive system for developers.  We have moved away from the
>>> concept of an exquisite personal computing environment to something 
>>> much
>>> more rigid and prescriptive.  This may put people off adopting such 
>>> an
>>> approach, but I think stability and flexibility are mutually 
>>> exclusive
>>> goals.
>>>
>>> -- conclusion --
>>>
>>> Due to Squeak's origin as a personal computing environment, it has 
>>> never
>>> had a way of allowing a large group of developers to work on it and 
>>> re-use
>>> each others' artifacts.  Current efforts are attempting to change 
>>> that,
>>> but there is no appetite for throwing the image away and starting 
>>> again
>>> with a small core - a very hard task, made harder by the fact that 
>>> all the
>>> development tools are in-image and need a larger core.  So the
>>> architecture of Smalltalk itself is against us.  Newcomers come in,
>>> realise that they can change the world in Squeak, do so, and then get
>>> discouraged when their code no longer works in the next minor 
>>> version.  So
>>> they put Squeak away - nice toy, unsuitable for me - and go back to 
>>> perl,
>>> or Java, or .Net, or something that has a stable core and where 
>>> their code
>>> won't break in the next minor revision.  And it takes them more 
>>> effort to
>>> develop in that environment, but *much* less effort to maintain.
>>>
>>> I admire Craig Latta's work on small images that do not contain a
>>> development system.  If we are ever to build a Squeak that allows 
>>> many
>>> developers to work in parallel, Craig's work - or something very 
>>> similar -
>>> is going to be pivotal, as the *only* way to build and test the core 
>>> parts
>>> of such a system.
>>>
>>> I'll leave you with one last puzzle: why does majorShrink exist?  Why
>>> isn't it majorGrow?
>>>
>>>                 - Peter
>
>




More information about the Squeak-dev mailing list