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