Squeak Starter

Andreas Raab Andreas.Raab at gmx.de
Thu Oct 17 15:56:45 UTC 2002


Hi Göran,

> > I have always liked (I still do) the general approach
> > that Henrik took due to its nice algebraic properties 
> 
> That is nice to hear - then I am not alone in thinking that 
> at least the ideas are "ok".

You might want to be careful about interpreting me that way. When I say
I like the "algebraic properties" it does not automatically imply that I
think they're a "good idea". Some of them I believe aren't. Or rather
"aren't for people".

  "One must learn to distinguish between 
   what is true and what is real"
     - A. Einstein

Here is a simple one: Giving the module-hierarchy a "meaning" of any
sorts. It's a perfectly fine thing to do in abstract algebraic
environment but once it comes to modules and (more importantly) to how
people _use_ them, it becomes very quickly clear that there's simply no
unique meaning for a hierarchy. E.g., when you organize stuff
hierarchically there's simply no unique scheme by which you go - I find
myself using various models each of which depends on the concrete
context I'm in. I thought about this for a long time (and had a couple
of good discussions with Stephane about this point) since I used to
think that a meaning in this hierarchy would be really valuable but in
the end I decided that while it is "algebraically nice" it is still not
a "good idea" for a module system to imply any meaning in hierarchies.

Similar for name spaces. From a more abstract point of view, it is
perfectly legal (and very useful) to give each module its own name
space. But when it comes to practical use ... uh ah ... Like Avi was
saying, is this really the big problem? (or in other words: a "good
idea"?!)

That said, I still think that parts of the design ideas are brilliant.
Conceptually, I _love_ the idea of delta modules as being the "bridges"
across different parts of the environment. Stephane has a valid point in
his argument about how to explain these but I believe that a lot of this
can be hidden - e.g., does a user _ever_ have to see the deltas?! I
would argue that he doesn't - from a UI point of view the system could
handle the "delta separation" while giving you the view of that module
as one homogenous entity. I claim that for 99% of all cases this is just
what you need and then you get all the other nice properties from it for
free (oh, and just by the way, I do _not_ like deltas for replacing
change sets - they serve very different purposes in my understanding).

> > Also, there's this problem that at this point there
> > is not a single concrete advantage for anyone actually
> > using the module system - it's still in an abstract
> > place in the future where "everything is going to get better" etc.
> 
> Yes, this is also the main reason IMHO that so few are trying
> to push 3.3 ahead. As Avi wrote - (paraphrasing) if I can't work
> *in* it then I won't work *on* it.
> 
> That is probably... THE biggest problem with 3.3 and Modules.

No, actually I don't think so. I think the biggest problem is complexity
and backwards compatibility. There are not very many people who really
_need_ modules in a deep way (if there are more than ten people on this
list I'd be surprised). Those who do have probably looked at the modules
stuff. Let's take Avi (it would be worthwhile if you could say a few
words about this yourself) and ask the question why exactly he hasn't
done his work in the context of 3.3alpha?! For the things that I did,
the answers are: #1 I need this with serious amounts of stuff working
within 3.2 and porting (and while porting finding and fixing bugs in the
module system) is not really an option. #2 It's been too hard to fit
into specific places of the modules system because you got to understand
too many of the details.

For a community effort it might just not be a good idea to concentrate
that many responsibilities in a single place. I think it'd be relatively
simple to handle all of the problems independently (e.g., source code
access, class definitions, versioning, packaging, name spaces) and then,
once the individual parts are there have a brainstorming session about
who should use what in which context and how they all play together. At
the very least people could try out individual stuff (which - as your
and Avi's work show - is useful on its own) before they buy into the
larger changes. Sure, it may not be as nice of an algebra, but I think
it'd be much more "real". 

> But does this mean we should drop Modules(as in Henrik's code)?

I told you, don't expect any answers from me. I would find it a horrible
waste of effort to dump all of it in particular considering the nice
stuff that's in there. That said, I do believe that the only way to make
this module system work is to have someone who deeply understands the
overall design and is willing to "carve out" small enough tasks for
collaborators which will in the end lead to a working overall system. I
can't be that person (I simply don't have time for it) and Henrik
doesn't either. Who else could and would?! And given that there's no
benefit for anyone at this point the question needs to be asked if
insisting on "fixing it" is helping at all, or if it isn't rather
getting into the way.

Usually, I'd say "let's vote by feet" and bring in the alternatives and
may the best code win. Unfortunately, it's not that simple with the
modules since they are not easily "extracted" from the system (remember
the "modularizing modules" thread?!) and the incompatibilities make it
even harder.

Cheers,
  - Andreas




More information about the Squeak-dev mailing list