Diego Gomez Deck wrote:

> The point here is: You have an object and you don't known what messages 
> you have to send? No tool can help here.

Actually, all a static type system does, is giving you and the 
browser/editor an idea of what kind of object do you have here and what 
you can do with it.  So, yes, the tool can help because the chances are 
high that if I don't know, at least the tool does.

As I tried to explain, in Java for example, it's mch easier to undestand 
new unknown frameworks once you've at least an idea what's going on. 
Just type

   aButton.

and search the presented method set.  If you know (in Java) that 
accessor method are prefixed with get and set and guess, that the 
buttons label is called text, you can find the setText() method.  You 
immediately learn that it needs a string as argument which as to be 
filled in.

Of course, using a second browser, you can also search a Smalltalk 
system, but that's much more difficult IMHO.  You have to interrupt your 
code writing, change to a second window, remember the type you where 
looking for, try to find all classes which fulfill that type (a manual 
step), browse their methods (another manual step), find the method, copy 
its name (yet another manual step) and switch back to the first browser. 
  Alternatively, you can just guess the method name and globally search 
for implementors, then choose some method for an interesting looking 
class (you have to remember the class hierarchy and the type->class 
mapping as the method browser doesn't show) and continue as above.

That is - IMHO - not as comfortable as a modern IDE (like Eclipse) with 
code completion is.

> Could be, but the types generate more "rigid" (dead?) system more 
> difficult to refactor.

Actually, I find refactorings much easier to do in a system with a type 
system. I wouldn't call that dead but well documented.  And, you'd 
probably agree, documentation helps refactoring.

Let's say you want to rename the method at: in your class to something 
better and also rename all senders of that method.  You're lost in 
Smalltalk.  Too many other classes also implement at: and it's very 
difficult to guess, which senders call your method and which not.  So 
this refactoring is more a trial-and-error operation than a (how is that 
called) a semantic-conserting operation.

>>   They also provide some help for refactoring - there're of course no 
>> unit tests so you better don't change what you don't understand 
>> because you cannot break a system which is in use by more than 500 
>> in-house customers.
> 
> I feel that here is the main point:  UnitTest.

If you have a language and a system which requires unit tests, that 
could be as good as better documentation via types.  However, as long as 
unit tests are voluntary, they don't really help.  Additionally, while 
it's a working quite well to test your core business model, it's much 
more difficult to test your UI.

And there's another point with unit tests. As they're written in the 
same language and are always run together with your code, can you assure 
that the semantic of your program doesn't change if you don't run them? 
  A declarative type system (which isn't run anytime) cannot affect your 
code.

> In my experience, I never had a "type error" in my systems that the 
> unit-tests can not find. (And all of these errors was fixed in minutes 
> in the debugger).
[...]

> I had exactly the same type of problems in "sure" typed system (to say: 
> Java).  With other problems: (classIsNotAnObject, nullIsNotAnObject, and 
> a large list of etc)

IMHO, both class cast and missing object errors are showing holes in 
Java's type system.  A true static type system will have them.  See 
nice.sourceforge.net for a nice language with an IMHO good type system. 
  Actually, that languages looks pretty damn interesting.

A common class type shouldn't include the Nil/null-type.  If you declare 
"a will contain integer" than this should means, integers only, not 
integers or no object at all.  If you want - like databases do for 
example - a variable that can also be "nil", then you have to declare 
this fact.   You can get rid of class cast exceptions by better use of 
polymorphism.


bye
-- 
Stefan Matthias Aust   //
www.3plus4software.de // Inter Deum Et Diabolum Semper Musica Est