Two important issues...

Stephane Ducasse ducasse at
Sun Feb 16 16:40:38 UTC 2003

Excellent email!
If mines would be of that quality. Thanks for your time andreas.

Back latexing....


On Sunday, February 16, 2003, at 05:33 PM, Andreas Raab wrote:

> Göran,
>> So... please tell me that I am paranoid and that the above will not
>> happen. :-)
> You are paranoid and it will not happen ... if and only if a gradual 
> model
> of adoption can be developed. That's the key point (always has been). 
> If
> there is a gradual path to transitioning into this universe, one in 
> which
> people can safely try out the advantages of the approach then it's 
> simple -
> just declare traits as a prerequiste for your stuff and start using it.
> The problems you describe only happen if everyone is forced to buy 
> into some
> new technology while it is still in flux (such as happened with 
> modules).
> Gradual adoption also has advantages for the developers of the new
> technology - it allows them to see how their stuff is used in practice,
> learn from it and get to the next level.
> For example, I am certain that Nathanael would like to learn more 
> about the
> practical implications of a wide-spread use of traits. While everyone 
> in
> Berne probably understands the model it's always slightly different 
> when
> things get out into the hands of the unwashed masses (no offense meant 
> - in
> the case of traits, I consider myself to be part of it).
> Here is what I would propose for the particular case of traits: Define 
> the
> fundamental invariants upon which the traits support relies as 
> "frozen" - no
> changes will be done in those (probably very few) areas in which the 
> traits
> support hook in. Possibly, do some slight modifications of the Squeak 
> kernel
> in order to provide a documented hook for traits support. For example, 
> I
> think that traits require some extensions to ClassDescription and those
> could make it to the Squeak kernel. Then, the ground is set so that 
> people
> can easily install traits into their system without fearing to break
> anything. The developers of the model know which hooks they can rely 
> on,
> which invariants *will* be supported by the Squeak kernel as of 
> version X.
> Knowing Nathanael, I am pretty sure he can pin-point those places that 
> need
> to be frozen in order to support the traits model easily. 
> [Incidentally:
> This is the exact model that the VM uses for JIT support - it provides 
> about
> ten entry points into which a JIT can hook and those are all that's 
> needed
> and that a JIT can rely upon].
> I can put this into simpler terms if you want: Make it so, that traits 
> can
> be trivially installed if wanted. Make it so that the absence or 
> presence of
> traits does not fundamentally break the system. Make it so that it is 
> clear
> where the intersection of the system with traits lives (so that, for
> example, modifications to system-level aspects can be done knowing 
> whether
> it will interfere with traits or not). Make it so that users of traits 
> can
> simply declare the need for traits as a prerequisite for "their 
> stuff". If
> that means we need to do a few modifications to the Squeak kernel then 
> let's
> do that. Having worked with Nathanael, I trust him to bring the traits 
> model
> to a point where the value to the community is obvious (he's just a
> perfectionist ;)
> A much harder, yet completely independent question is whether to apply 
> some
> of the existing refactorings (such as collections) right away. My 
> essential
> feel here is: Don't. Traits "ought" to be able to provide value 
> outside of
> just those refactored places and if that's the case, then we should 
> start
> out using them wherever we want. The existing refactorings still 
> provide
> value in such that they are examples of what you can do with the 
> system,
> where and how one would use traits. However, whether collections are
> implemented using traits or not does - for a user of Squeak - not 
> matter. As
> long as collections understand the right protocol, everything is fine. 
> Using
> this model, e.g., for the time being not apply any refactorings to 
> critical
> places of the system buys all of us time to judge the implications, to 
> find
> out where and how to use traits, to learn and see how it works out 
> (both,
> for users and developers of traits).
> At the point where a significant number of developers *do* understand 
> the
> value and the advantages of traits, we will have a trained set of 
> people who
> could (if it ever comes to that) support the model "without living in
> Berne". Those people are likely to raise the point that it's quite 
> stupid to
> require traits for about every interesting bit of code in the 
> community, but
> have the kernel places not use them. That would be the time by which 
> those
> refactorings can be applied easily - and I'm pretty sure that at this 
> point,
> the questions you are raising won't even come up.
> Cheers,
>   - Andreas
>> -----Original Message-----
>> From: squeak-dev-bounces at
>> [mailto:squeak-dev-bounces at] On
>> Behalf Of goran.hultgren at
>> Sent: Sunday, February 16, 2003 3:00 PM
>> To: The general-purpose Squeak developers list
>> Subject: Re: Two important issues...
>> Standing on the side here...
>> A few of the postings from Stephane has probably
>> mistakenly/unintentionally sounded like "Ok, Squeakers - either you do
>> this and this or we will leave...". I understand Jim's reaction, but I
>> don't think it was intentional from Stephane.
>> Ok. But there is indeed one important thing to note here -
>> and please -
>> these are just my personal reflections.
>> As one of the people committed to Squeak I would not like us to adopt
>> technology that will really affect Squeak to the core - if not the
>> principal people behind that technology is devoted to Squeak
>> and to the
>> community and will "hang on even if the road gets bumpy". What am I
>> trying to say? Well, I would really hate the following scenario:
>> 1. The community adopts Traits (still a long term gradual thing of
>> course). Nathanael is AFAIK the principal engineer behind the code.
>> Perhaps this stuff is so complex and to the core of Squeak that few
>> others can help out and/or maintain it.
>> 2. Along the way "the guys in Bern" decide that, nah - Squeak
>> wasn't the
>> proper vehicle for our research. It may be due to some choices in the
>> community that doesn't turn out to the liking of "the guys in
>> Bern" - or
>> whatever. And "the guys in Bern" simply jumps off the ship and start
>> using Smalltalk-younameit instead.
>> And then here we are, left with a system we don't understand, with a
>> halfbaked new browser/parser etc. etc. That wouldn't be good. It could
>> all turn out similarly to 3.3alpha (even if it would be partly due to
>> other reasons) where we ended up with a halfbaked system we couldn't
>> move forward.
>> So... please tell me that I am paranoid and that the above will not
>> happen. :-)
>> regards, Göran
Prof. Dr. Stéphane DUCASSE (ducasse at
  "if you knew today was your last day on earth, what would you do
  different? ... especially if, by doing something different, today
  might not be your last day on earth" Calvin&Hobbes

More information about the Squeak-dev mailing list