Improving the aesthetics and usability of Squeak

Andreas Raab Andreas.Raab at gmx.de
Tue Jul 9 00:32:32 UTC 2002


Stephen,

> Getting modules nailed down seems like a very reasonable 
> initial step, as Alan Kay noted earlier in the thread. 
> That will help give some space to all the furry little
> mammals to play in the same world as the big dinosaurs
> without getting trampled, as it were.

I didn't want to write this message before but I think it's time to take
an illusion from all of you. I have the impression that a majority of
people on this list believes that modules will solve "all the problems
of Squeak". This is wrong on many (if not all) accounts.

Point #1: I presume that being "trampled upon" means that things keep
changing rapidly under your feet. Modules will not solve that problem.
They will not because we will still maintain an incremental update
cycle. If you were using stock-releases then *nothing* has changed since
the last release. With modules things will *still* keep changing between
releases. Or do you realistically expect that we won't change anything
anymore just because now they're in a module?

Point #2: Modules will not solve the problem of integration. If you
expect that it's easy for you to make some module and it will
automatically work for the next ten generations of Squeak then re-read
point #1. Committment is required, you cannot stand off and say "because
I made this a module it's going to work forever" (this is a point of
view that I see implicit in many opinions voiced about the module
system). True, modules will help to *identify* existing and potential
problems but someone will still have to review them and fix things as
appropriate. Personally, I have the impression that at least some people
think that having modules means handing things of to some central
authority, which will then do the maintenance and integration work from
there on. E.g., basically handing off "the module" and never again worry
about it. This is wrong, both conceptually and practically. If you need
an example, come over to the SqModules mailing list and see how at times
we are wondering how things "were planned to work".

Point #3: Modules will not solve the problem of what is in the "base
image" and how to find things that are not in. What is needed is a
community place which is generally accepted as a source code repository,
a place both well-populated and well-maintained, with people presenting
their work or that of others. Some newsletter for example, which a
person with writing skills could set up to inform the community about
ongoing developments. Some good soul collecting cool, interesting or
just fun stuff and have it ready at a single click. This issue is
entirely unrelated to modules (and in fact, one of the things that I
proposed to SqF for raising the visibility of itself).

Point #4: Modules will not solve the problem of what "the default
experience" should be. While it may make it easier to have a variety of
looks and content someone still has to make the ultimate decision about
what the standard should be like. Most people never change the defaults
so that decision is important and has to be made very carefully. Modules
don't help the least bit to actually make that decision.

With all that said, I still think it's crucial to get the module system
off the ground, and if you have a bit of spare hacking time then
*please* come over to SqModules and help us. But just don't expect
unreasonable results from that work.

Cheers,
  - Andreas




More information about the Squeak-dev mailing list