Hello,
[snip]
All these kinds of things are very important if you have to work with complex frameworks and/or other people's code, often poorly written, and need to get a good understanding of what it does, and what not.
In Smalltalk (without types) no tool can exactly know the type of an expression and code completion (with is IMHO the best productivity tool of a modern IDE) cannot offer a valid selection of applicable method names.
The point here is: You have an object and you don't known what messages you have to send? No tool can help here.
Currently, I'm working with a very large (VisualAge Smalltalk project which was grown over the last five years or so - and most original developers left the company long ago - and it's awful difficult, I want Eclipse (and Java) back. Never thought, that I'd say that but if mediocre programmers hack quick fixes into a system for a couple of years, Smalltalk becomes a mess. This is probably true for other languages, too, but at least types would give you some kind of documentation.
Could be, but the types generate more "rigid" (dead?) system more difficult to refactor.
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.
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).
Smalltalk + UnitTest = StrongTypedSystem?NoThanks
I found it much easier to get my way through the Eclipse Java source code.
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)
[snip]
Stefan Matthias Aust
Cheers,
Diego Gomez Deck