Hello,

>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.

Let's suppose this is the first time with aButton.

I'll white this code:

     self halt.

Then I'll open an Inspector for aButton and play with it until I get enough 
knowledge of it.

 From the inspector I'll try to change the name, send other objects as 
names (not only Strings) to get the felling of what can I do this it, etc, etc.

Play with objects, don't read code.

>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.

No... I don't use any of these options.  I use the Debugger and Inspectors 
to play with objects and this is comfortable to me (and really funny!)

>>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.

The system is documented, not ever well.  The documentation shows the point 
of view of the writer in the moment of writing the code.

>   And, you'd probably agree, documentation helps refactoring.

That true only when the documentation is up to date.  I spent several 
hours/days/weeks/etc refactoring documentation before the code.

>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.

Yes... It's trial-and-error, what is wrong with this?  How did you learn to 
walk, talk, etc?

>>>   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.

If you have programmers trying to write bad code, you'll have bad code 
anyway.  Writing unittest is voluntary just like write any code. In a typed 
system you can find method using Object in every where and casting all the 
time.

No tool/language can convert bad programmers in good ones.

>Additionally, while it's a working quite well to test your core business 
>model, it's much more difficult to test your UI.

Testing the UI is an open problem.

On the other side, the code in UI with typed languages is extremely more 
complicated than in ST.

>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?

I don't follow you. What means "if you don't run them?"

>A declarative type system (which isn't run anytime) cannot affect your code.

A declarative type system affect my code too much.  The models generated 
most of the times are more complex than the equivalents without a typed 
system. Do you want an example? EJB.

[snip]
>bye
>--
>Stefan Matthias Aust

Cheers,

Diego Gomez Deck