What we want with Squeak?

Daniel Vainsencher danielv at netvision.net.il
Tue May 6 11:29:04 UTC 2003


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