Two important issues...

Nathanael Schärli n.schaerli at gmx.net
Sat Feb 15 15:05:06 UTC 2003


Hi Jim

I'm also not quite sure what you imply. However, since I work closely
with Stephane, I would like to clarify a couple things:

- My primary interest in traits and all the other language design issues
are academic. I'm a CS Ph.D. student and this is just part of my thesis
work.

- Since I'm not a language designer that likes to propose and reason
about theoretic models only, it is very important for me to implement my
models. However, I simply don't have the time to make all of these
implementations stable and ready for integration into the main image
immediatly.

- I have been doing all my programming work in Squeak for a couple of
years. I love Squeak and I have a honest interest in contributing to it
and making it better. Nevertheless, we need and want to make sure that
we pick a platform that allows us to implement a prototype version of
our models in a reasonably fast time and without too much pain.

That's why we are evaluating the different alternatives: Squeak,
SqueakScript (Andreas Raab's stuff), or maybe even something else. And
since we want to communicate about this process and inform people why we
are thinking to do one or the other, Stef informed what are the things
that make us think whether Squeak is the most effective platform.
However, this has _nothing_ to do with "threatening and make Squeak
comply" at all! (I know that Stef's emails are sometimes a bit short and
direct, but everyone who knows him also knows that he doesn't mean it
like that).

Nathanael



> -----Original Message-----
> From: squeak-dev-bounces at lists.squeakfoundation.org 
> [mailto:squeak-dev-bounces at lists.squeakfoundation.org] On 
> Behalf Of Jim Benson
> Sent: Samstag, 15. Februar 2003 11:44
> To: The general-purpose Squeak developers list
> Subject: Re: Two important issues...
> 
> 
> Dean,
> 
> >From what I've seen the last couple of weeks, there are several other
> factors in the Traits decision. From what Stephane Ducasse 
> has reiterated a couple of times, that project requires that 
> they need: (Squeak to)
> 
> [quote]
> - In all cases we need a stabler Parser, cleaner AST, 
> ClassBuilder, and BROWSER. So we will see if we can get some 
> momentum and synergy with SqScript, in such a case we will 
> see if we use SmaCC, redo ClassBuilder. Else we may end up 
> moving to another Smalltalk. [/quote]
> 
> Don't know about you, but I've never seen a tree those things 
> grow on. We've seen the part about Ducasse threatening to 
> switch to another Smalltalk a couple of times if somehow 
> Squeak doesn't comply. [We both know it cannot; the above are 
> cross purpose with the current 'rip the image apart' stuff 
> going on which will probably take several months. It would 
> not make sense to rip the image apart and introduce 
> potentially unstable underpinnings both at the same time. 
> Unless I miss my guess, the introduction of new code into the 
> image other than bug fixes or relatively simple reorgs will 
> probably not happen in the near future]
> 
> >From the tone of the emails, it has sounded like someone has been 
> >holding
> these things back, keeping these prerequisites for the Traits 
> project from being available to Squeak. I haven't been 
> following this thread very closely, but I would like to know 
> who is responsible for keeping this code away from us. I 
> don't recall seeing the new browser that Ducasse submitted 
> for inclusion, is someone hiding it from me?
> 
> Thanks,
> 
> Jim
> 
> PS: I didn't realize my AST was dirty, or that I needed to 
> clean it, but hey, that's me.
> 
> ----- Original Message ----- t
> From: "Swan, Dean" <Dean_Swan at Mitel.COM>
> To: "'The general-purpose Squeak developers list'" 
> <squeak-dev at lists.squeakfoundation.org>
> Sent: Friday, February 14, 2003 7:44 PM
> Subject: RE: Two important issues...
> 
> 
> > Just to voice my opinion, I agree with Daniel on this.  I 
> feel like I 
> > want
> somebody to convince me that Traits is something I need.
> >
> > I don't really understand Traits too well at this point, 
> but I agree 
> > with
> Daniel that it seems to be of greater value for refactoring 
> existing code than it is for writing new code.  How is this 
> different from AspectS and Perspectives, or mix-ins for that 
> matter?  My cursory (and perhaps
> incorrect) understanding leads me to believe that Traits is 
> just another "flavor" of the same kind of thing.
> >
> > Have there been any costs/benefits analyses done of this kind of 
> > system?
> While I understand that it allows for a higher degree of 
> reusability, I'm not convinced (yet) that it's worth the 
> complexity it can add to the inheritance graph or the greater 
> potential to break more classes faster by changing a highly 
> reused method at the Trait level.  I understand subclassing 
> and overriding a method from a superclass.  Traits is more complex.
> >
> > Along the same line of thought, I wonder just how much utility can 
> > really
> be had from Traits?  Would refactoring the Collection 
> hierarchy, for example, with Traits reduce the number of 
> methods? code space? increase performance?
> >
> > I would hate to see Squeak/Smalltalk gain as much "flexibility" as
> something like C++.  Will Traits make it any easier to do 
> ill-advised things (i.e. write bad code)?
> >
> > Traits strikes me a little like the kind of thing an optimizing 
> > compiler
> might do "under-the-hood", but it's not clear that this fine 
> grain control is a "Good Thing"tm at the source level.
> >
> > I am not saying that Traits should never be a "CORE" 
> package, but IMO 
> > it
> is  FAR to early for it to even be considered for that yet.  It would
> > be very good to see it used for some "real" code (as opposed to 
> > examples
> contrived to highlight the value of Traits) so we can get a 
> feel for where the strengths and weaknesses are.
> >
> > To me, Traits is a much more experimental technology than Anthony's 
> > VI4
> work (full closures, context stack unwinding, etc.), so I'm a 
> bit wary.
> >
> > -Dean
> >
> 
> 



More information about the Squeak-dev mailing list