What we want with Squeak?

goran.hultgren at bluefish.se goran.hultgren at bluefish.se
Wed May 7 09:45:41 UTC 2003


Hi all!

Now I have read through this long thread and want to chip in. :-)


* Regarding how we develop Squeak and trying to use XP more:

We are all different. Period. Open Source projects like Squeak with
numerous developers scattered geographically using spare time simply
doesn't work with methods like XP. And people are doing this for fun and
want to work the way *they* like to - not using some method someone else
tells them to use. I am exaggerating a bit here to make my point. We are
trying to establish some standards like increasing the use of Tests etc.
but going much further than that is IMHO not good nor possible. Let
people have fun!


* Regarding packages vs images:

We will have both. Period.

Splitting the image into packages is mainly about clearing up the
dependencies. And when we do that we also gain the capability of being
able to have pieces of the codebase installable. Today SM feels like a
remote kindof repository (which it isn't - its a catalog) but in the
near future it will have a proper cache and hopefully people will see
that the end user experience will not be harmed.

Essentially this is how it will work:

1. You download Squeak. You selected to download the smallest zip-file
because you are on a modem. You get the smallest image and a filetree
with packages (the package cache of SM).

2. You fire up the image and read in a window that you can build a full
developer image or an even fuller "the works" image with a single click.
You pick the developer image. Squeak installs what it needs from the
local cache (no net involved) and let you save the new image.

3. At this point you are more or less where we are today. Knock yourself
out.

4. You look in the package loader and see that there is even more nice
things to load - hey, 5 different libraries for remote object calls, 3
different webservers etc. Yummy.

Now, please explain to me what you don't like with this picture.


* Regarding Bob's fear of loosing the synergy effects of a common
ground:

This one is IMHO the only interesting issue raised against the current
planned future. I have also thought about it. What happens when people
sit in different images and don't see the same things?

"Hey, just use class JumperThingy! What? You don't have that class? Oh,
sorry - it's in package Blammer."

Personally I think this is an important issue we need to try to address
as much as possible. For example - today you can select "senders of" and
get a list of senders. None? Aha, nobody uses that method - alt-x. :-)
But hey, nobody *in the image* uses that method. But what about packages
not installed? Many may say this is a new problem coming but it isn't.
We have had it all along - code outside of the image has been rotting
like hell because of Squeak changing beneath their feet. People have
even gotten to the point where they don't bother to port stuff to Squeak
because it will just stop working in the next Squeak release! Ooops -
isn't that a wake up call?

Having a proper SM we at least have a *chance* to make this situation
better. We could even create a "database" of senders/implementors that
have the information from *all* packages on SM. Think about that.


* Regarding all you that want a single image and no packages:

I may have already written about this above - but anyway...

How are you then going to cater to all the conflicting code packages out
there?
In one image "there can be only one" of each and every thing. One
library for doing remote calls. One webserver. And so on. Sure we could
try to stuff *everything* currently on SM into the image but hey - that
would not work, there is simply too much out there! So what do we choose
then? And who gets to choose? And what happens to all the other packages
that aren't allowed into the image? They turn into second class citizens
and rot away.

Face it people - if Squeak will be able to sustain the growth and be
able to scale with the community we *need* packages. But... that doesn't
mean we need to sacrifice the ability to simply download a rather big
and juice image and be happy. We have repeatedly explained that we aim
to have three of those available for immediate download.

Sorry for the long post.

regards, Göran



More information about the Squeak-dev mailing list