[ENH][Modules] Delta Modules [was: Another version]

Andreas Raab Andreas.Raab at gmx.de
Mon Oct 22 19:12:21 UTC 2001


Andrew,

[Sorry for the delay but Goran's message reminded me that I wanted to write
a reply to your message but it moved down too quickly].

> I'm giving up on this thrust.  It seems clear that I am not the only
> person with qualms about the way that the module system is
> developing, but it is also clear that nothing is going to change
> because of further discussion here.

I know you are concerned and many other people are concerned. However, I do
have the strong suspicion that we're seeing a "second system effect" at a
very large scale here. If you go over all what has been said about what a
module system _must_ do then you may get pretty cautios about implementing
all that has been said. Now, this is not to say that these points are
invalid and make no sense, but putting various pieces together doesn't make
a consistent design idea. In fact, ever since these discussions started my
biggest concern was that Henrik's simple idea gets screwed by all these well
meant suggestions (one might take a stronger word than "suggestion" for some
of the proposals but I still treat them as such ;-)

[Incidentally, while I have critized Ginsu for staying basically "secret" I
need to say that in hindsight this appears to have been a very smart move.
At least it avoids most of the noise of early discussions - and if there's
really something missing you _can_ change it. I'm sure most of what has been
said in all these messages could have been applied to Ginsu in an early
stage as well]

[Re: XP]
> I belive in XP, and I've seen XP work well, and XP certainly has the
> flavour of implementation first, description later, if at all.  But
> XP has other principles and practices that protect the team while
> working in this style:
>
> 	* There is a user story that defines a goal for each
> coding effort
> 	* There is continual face-to-face communication between the
> members of the team
> 	* There are tests, both unit tests and customer-defined
> acceptance tests
> 	* There is a system metaphor, which guides the implementation
> 	* The programmers write the simplest thing that could
> possibly work.
>
> The reason that I'm concerned about the current work to implement a
> module system is that it seems to lack all of these attributes.

Hm. Well. Let me ask you a simple question: If you have a TrueType glyph and
want to come up with polygons for the filled parts, would the "simplest
thing that could possibly work" be a constrained delauney triangulation? It
would, for *me* (and every other graphics person). And it would also be the
canonical solution. The point I'm trying to make is not to confuse "simple"
and "canonical". I would agree that Henrik's solution is not canonical, but
how can you know what the simplest thing is for any of us? Similarly, the
effect that we cannot _explain_ the user story in the right words to you
does not mean there _is_ none. In fact, I've personally written a message
about "how you can think about" some this stuff and I would consider this to
be a user story - wouldn't you?! Lastly, the best test for a module system
is to actually use it, and the code allows exactly that ;-)

> Which is why I thought it important to come to an agreement on a
> simple semantic model before implementation started.

Did you read all of the discussions?! Do you have any hope whatsoever that
there might be a general agreement on such a seemingly simple issue?! I
don't :-(

> It's also clear that email does not take the place of face to face
> conversation.  I've been asking what I though were simple questions,
> and Henrick needed 12 kB of email to respond -- but never actually
> answered them.  I'm not expecting you to spend more time answering
> this, but I hope that you will take the opportunity to come to Bern
> and visit with Stephane and myself, and see if we can't bridge the
> semantic gulf that seems to separate us.

I agree that email (in particular on a public mailing list where it can
generate a lot of noise) is not a very good solution. I'm certainly planning
to come by (and I'm actually looking forward to it :-) BTW, I don't really
think there's a semantic gulf between any of us - Henrik's solution is a bit
out of the ordinary but that doesn't mean it's adressing different problems.
Unfortunately, it seems to require an "aha!"-effect which appears to be
harder to grok for people who "know" how module systems must work (too much
prejudice I suspect - if they don't find all the stuff they're familiar with
it can't be the Right Thing).

Cheers,
  - Andreas





More information about the Squeak-dev mailing list