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