> Other systems have found pretty reasonable ways of dealing with it (or 
> at
> least so I think). For example, using a "layered" language approach 
> could be
> helpful. On a low level, there is a "kernel language" and on top of it 
> sit
> all of the added elements (syntactic or semantic sugar). Pretty much 
> the
> only thing one needs to make sure is that every program in the kernel
> language is also a valid program (with the same semantics!) on the 
> level
> above.

Yes the scheme macro for example. I would really like to know what is a 
good macro system
for a Smalltalk.

>> I want to propose further tools/environment hacks that might
>> alleviate some initialization problems without breaking the
>> code model (modeled on our existing hacks to generate accessors) -
>> 1. A class-side DNU which looks up the message on the
>> instance side, and if an implementation is found in the initialize
>> protocol, creates a method that calls it. So if we define Point>>y:x:,
>> then Point y: 5 x: 3 would DNU, find our method in the right category,
>> and define
>> Point class>>y: yValue x: xValue
>> 	^self basicNew y: yValue x: xValue
>
> That's about the worst solution I can imagine. It would mean that 
> whenever I
> have a mistake in spelling a method I get a new initializer on the 
> class
> side. Even worse, I would imagine that this is being instantly abused. 
> There
> is _intent_ on the side of the person who is creating the last and the
> constructor needs to recognize this intent.

I agree. we could also have a instance variable created automatically 
when you mistyped
a variable as in certain language :)

>> 2. A menu option for methods "make initializer" that
>> generates the stub described above on the class side.
>
> The biggest complaint I have about this is that it's not descriptive. 
> If we
> want to defer exposure to the meta level for a while we need to be 
> able to
> _recognize_ constructors when we look at classes (e.g., is there an
> initializer for PluggableListMorph?).

Agree too, andreas for once we are in sync.

we had a lot of discussion with nathanael about what is in the language 
and in the UI.
This is cler that a clever IDE can help a lot but the language is what 
you write by hand.
My gut feeling is that a language should be useable without an advanced 
UI but may be this is
too much oriented vi/emacs approach. May be I'm wrong.

Stef