Hi all!

=?iso-8859-1?Q?Nathanael_Sch=E4rli?= <n.schaerli at gmx.net> wrote:
> Hi Goran,
> 
> > 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. :-)
> 
> I agree with you and I think it is very important to distinguish between
> a nice and very promising research model/prototype and a language
> extension for _real_ language like Squeak. At the moment, traits really
> are still on the prototype level and we have still a lot more ideas of
> how to make an extended and much more poweful version.

Noted. So perhaps it was a bit early for me to set off this discussion -
but I did it because it really is an interesting problem not only
regarding Traits. It just happens to be the best example. :-)

> Since the model of the current version is relatively stable, it would of
> course be possible to take it and implement a productive version of
> traits for Squeak right now. However, in order to do this right and
> clean, this would require a lot of preliminary work on the language
> kernel, the browser, etc. Once this were done, introducing traits would
> actually be _very_ simple: Remember that traits are essentially just a
> group of methods that can be reused and shared between different
> classes. Since ST has the concept of first-class method dictionary, it
> is therefore nearly trivial to accomplish that! 
> 
> This means that implementing traits in the right way on a clean basis
> really does not make the system much more complicated, and everyone who
> understands the current kernel can easily understand the extended

Sounds reassuring.

> kernel. However, this is only partially true for the current prototype
> implementation. This has several reasons: I didn't quite now where I was
> going when I started and therefore I definitely didn't always choose the
> best design decisions. And even if I knew what would be the best thing
> to do, I sometimes didn't do so just because it was not worth the effort
> for the prototype implementation I needed for my research. However, one
> of the main issues definitely was that there are so many places where I
> had trouble with existing parts of Squeak. Whether it was the parser,
> the kernel, the browser, it sometimes really prevented me from doing
> things the way they actually should be.

Ok. And just so that I don't forget - this work of yours is very
valuable. And I am not talking about Traits, I am talking about your
problems! We all want a better Squeak and you are probably sitting with
a lot of insight most of us don't have.

> Of course, I could have spent some time to fix or rewrite these parts
> first, but I simply didn't have the time for all of that. And this is

No, of course not.

> exactly what Stef tried to communicate:
> 
> If the Squeakers at one point want to have traits (and all its tools
> such as the browser and the realtime code analysis) in their language,
> it just is _necessary_ to clean up certain essential parts of the system
> first. And this is not because the "guys of Berne" say it, it is simply
> because this is the _only_ way of getting a clean, stable and
> well-understandable language.

I understand this, and so does hopefully we all. Btw, I only used "the
guys in Berne" because I don't know a better name for you guys! :-) It
was not meant as an "insult".

> In this case, I'm 100% certain that the nightmare you are afraid of
> (i.e., having a half-baked and buggy system noone understands) will
> _not_ happen. In the opposite, I'm sure that having a clean basis with
> traits would even make everything more understandable.

Also sounds good.

> But at the same time, more than a year of experience in implementing the
> current traits prototype in Squeak taught me that just "hacking" traits
> onto a messy and unclean basis may be enough for a research prototype,
> but it is not at all the right thing for creating a system people
> actually use for real work. And again, this is exactly what Stef wants
> to communivate when he says that Squeak needs to move a bit in order to
> be ready for stable and clean traits, and it is also the reason why it
> needs more work than many people think in order to convert the traits
> prototype implementation into a stable version. The current
> implementation really is a prototype and it is not ready for prime time.

Ok, so this means that we should not and probably will not see Traits
coming into Squeak core for quite some time (because even if we go full
steam ahead there's a lot of work to do).

But... we *do* still need to decide if we want to move in this direction
and how to do it:

We all want a better browser, a better parser/scanner/AST whatever and a
clean kernel.

Someone will have to do these things (surprise) and the parser/scanner
stuff might already be in the pipe since I read that Anthony is thinking
in moving the new Compiler in this direction. But for the rest I have no
idea - but why should anyone be opposed to these things? Stephane has
almost sounded as if there is a resistance in the community and AFAIK
there is none. Again, this is probably unintentional of Stephane and he
just wanted to tell us about your different "problems".

So I think this boils down to if you want to play together with us in
the community or not. I mean, if Traits enter Squeak as a "core" package
then it will not be "yours" anymore to do with whatever you please.

But lets say we get these things fixed together. What then? I am still
wondering about where Traits would "end up" in the different groupings
of packages and I am still wondering what this means - is Squeak not
Smalltalk anymore? And does it matter? It will still be some form of
superset of Smalltalk I presume.
---

Ok, perhaps the above thoughts weren't that structured. In short I (me,
Göran that is) would like us to all cooperate in getting the core pieces
done right (browser, compiler, kernel) - regardless of Traits. That is
simply about doing things right.

And then eventually I would like to see Traits enter core Squeak. I
think this would revitalize Squeak as a tool moving into the future and
not only being a mimic of some cool stuff people did in the early 70s.
Seriously.

And I would like to feel that the people working with Traits consider
Squeak both as the home of Traits but also as the community where Traits
grew and evolves.

regards, Göran