What we want with Squeak?

Stephane Ducasse ducasse at iam.unibe.ch
Tue May 6 10:37:39 UTC 2003


Hi daniel

I agree with you. Now we have the opportunity to change and we are 
learning
how to do it.

Stef
On Tuesday, May 6, 2003, at 01:29 PM, Daniel Vainsencher wrote:

> I think this generalization is not precise. I care about the media 
> stuff
> much more than I can about any of the "traditional squeakers" topics 
> you
> mentioned (cgi..).
>
> What concerns me, and motivated me to start pushing in certain
> directions, is that Squeak's direction had ignored some "economic
> principles" of software development, and as a result, really was dying.
>
> Think back to the final days of 3.3a.
>
> * Big untested changes can kill you
> Nobody is using the alpha version, because it's hard to develop in. 
> This
> is the direct result of accepting the Module code, which changed a lot
> of things, but was incomplete, and not widely understood. This code was
> accepted into the image because there was no other way for a module
> system to be posted for people to use. So the whole problem was an
> indirect result of not having mechanisms for people to easily see
> available projects. Hence the importance of SM, and of using it as a
> testing ground for serious chunks of proposed code.
>
> * Concentrated decision making about every little thing doesn't scale
> You might or not remember it, but harvesting had been very slow and
> erratic then too. This was because the process was such a pain, that
> nobody wanted to do it. I remember enhancements and fixes I posted to
> the list, that we're forgotten at some point by SqC, after they
> mentioned a problem in it, and then I fixed it - they never got a 
> single
> reply from anyone. Hence a new harvesting process, with explicit place
> for ANYONE to review code and state it is better or worse, and push for
> it's inclusion.
>
> * If you tolerate this (cruft) then your children will be next
> Even now, the image, from a software engineering perspective, is a 
> mess.
> Object (The Base Object) indirectly depends on well over half the
> classes in the system. This is why it is hard to make images for
> specific purposes - because everything depends on everything else.,
> because there are not module limits. Hence, we try to factor stuff out,
> and use new packaging mechanisms that allow clean extensions to classes
> like PackageInfo.
>
> These are pressures we simply have to respond to in order to keep 
> Squeak
> alive and changing. This is what interests me.
>
> What I think is being collectively expressed here by many people is not
> that "media is more important than web development". I think what 
> you're
> really saying is that the need for a rich loaded Squeak image is also
> critical, because that's what draws people to play with Squeak in the
> first place.
>
> Maybe we were wrong to think we can get away with a "lean" release that
> removes stuff, without addressing the "rich image" concern immidiately,
> by having official configurations and preloaded images.
>
> And I completely disagree with the sentiment that we don't have enough
> resources to cater to people with different tastes. This requires 
> moving
> to working with configurations, and this is a big change that is
> happening slowly. It also require everybody to be active about making
> their stuff viable and pushing it, correctly.
>
> Daniel
>
> diegogomezdeck at consultar.com wrote:
>> Hi,
>>
>> I think we're really near to find *the* source of all these 
>> discussion we
>> have periodically since SqC leaves Disney.
>>
>> What we want with Squeak? Clearly there are 2 groups:
>>
>>   - The "Media-Squeakers" (in Andreas's words)
>>   - The "Traditional-Squeaker" (in my words)
>>
>> I'll try to explain creating radicalized descriptions of these groups:
>>
>> The Media-Squeakers believes in Squeak as the most promising 
>> incarnation of
>> the Dynabook concept. These guys want TTF in the Image, Sound, Midi, 
>> PDF
>> support, SVG readers/writers, Improved Look&Feel, Video support, etc 
>> and
>> they are able to accept a big core image.
>>
>> The Traditional-Squeakers are more interested in "normal" development 
>> with
>> Squeak and they are interested in SOAP, Relational DB Access, CORBA, 
>> CVS
>> support, cgi-type web servers, native-widgets, etc.  These guys want a
>> really small core image with nothing more than stdio support.
>>
>> If we don't agree with the goals difficulty we'll agree on methods.
>>
>> We have to decide what we want with Squeak and accept that, probably, 
>> the
>> goals of these groups are not the same.  Personally I think we have 
>> not
>> enough resources to try to get all the goals of both groups.
>>
>> In the SqC age the Media-Group was in charge and Squeak has excellent
>> multimedia capabilities and absolute no support for "traditional"
>> development.   In the Guides-Age these goals, imho, are not so clear.
>>
>> Cheers,
>>
>> Diego
>



More information about the Squeak-dev mailing list