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
|