Hi Gilad,

> >I found the type-system the most unnatural part about StrongTalk.
> >It feels displaced and if you look at methods like "->" in 
> >Object you can see that there are some rather nasty complexities
> >associated with it (not to mention readability issues).
> 
> Indeed, no one claimed that designing a type system for  
> Smalltalk is easy and free of nasty complexities.

First of all let me say that I really admire what you have done. It is
always easier to criticize some existing design than to build a new one.
In fact, I wouldn't even have voiced my opinion if it weren't for the
fact that I found it almost impossible to ignore the types when just
looking at the code - they just seemed to be "in the way" when I was
looking at a method (this is what I meant by saying it felt displaced).
And examples like the ones that I have given were just particular
stumbling stones for me.

> As far as readability goes - it is still much better than not 
> having a type signature at all.

I don't know. It's one the things that is extremely hard to figure out
by newcomers. If the method is well written it usually states a goal and
the selectors used in the method itself often tell much more about what
is intended (since they are goals themselves) than any type could do. In
this light it is particularly interesting to me to see that in some
places in StrongTalk annotations for type annotations are used (like in
Object>>perform: which states "BottomType" with the annotation that what
really is meant is a Symbol). It is true that for somebody who knows the
class/type library the types itself might give some useful information
but more often than not I would probably prefer it to ask for types than
having them presented automatically.

> >That has been said many times and yet, I disagree.
> 
> We probably don't disagree as much as you think.

Actually I think we agree on pretty much everything except UI issues ;-)
I am in strong favour of types (optional or not) for ensuring system
consistency. It only troubles me if I think about the learning curve for
them and whether you really want to see them or not. It is for a reason
that many scripting languages (by which I mean languages used by
hobby-programmers and not by professionals) do not use static typing.

> There has been research on type inference for object oriented 
> languages like Smalltalk. Inferring all the types is a very hard 
> problem. Partial inference, on the other hand, may be quite
> straightforward.

Yes, this is exactly what I was thinking about.

> 1. In some cases, you must use type annotations. Whether that 
> is 10% or not is speculation at this point.
> 2. If you do have some annotations already, it is much easier 
> to infer the missing ones.
> It is therefore advisable to separate the problems of type 
> checking and type reconstruction (as type inference is more
> properly known).

Agreed.

> For example, we always wanted to add an "infer types" option to the 
> browser, which would attempt to add missing type annotations; 
> we never got around to it, but it certainly would be a nice thing to
> have.

Oh boy, that's *too* bad. Any intention to perhaps add it?! I'd be
delighted to see how much it can actually figure out.

> The advantages of the separation of type reconstruction ad 
> type checking are in some respects analogous to the advantages of
> separating type checking from execution semantics (aka optional
> typing). You avoid constraining one aspect of the language due to
> limitations of another aspect.

Very good points.

> >but I would hope that some better syntax can be found than
> >is currently in both StrongTalk and SmallScript.
> 
> I don't argue with people over surface syntax. It is a highly 
> emotional and subjective issue for people, even though it is
> fundamentally trivial. I will note that we had to retrofit a
> syntax that parsed, onto the existing Smalltalk syntax. This
> constrains things a good deal. Feel free to suggest 
> concrete improvements.

Well, one simple yet possibly helpful thing to do would be to make the
display of type annotations optional ;-) E.g., just something that
allows one to suppress types while reading some code and have the types
show up (either in some status bar or as a tool-tip like thingy) when
you mouse over. It's not actually the look of the type annotation itself
that bother me most (although I think that something better could be
done if you change the syntax a little more) it's just (my) inability to
understand the goal of a method if the types are "in the way".

Cheers,
  - Andreas