David Buck has an interesting item on the The Basis of Object Oriented Programming. Dominique Jocal, who is apparently a fan of static typing (which she mislabels as strong typing) commented

Are you saying you look at code implementation to know what "type" is expected ? Or there is a way to express this "requirement" in signatures with Smalltalk ? ...strong typing is the classical solution for javaists and C-sharpers. If smalltalk has a solution with dynamic typing, well, it's cool.

Actually, Dominique has a point. There is nothing in a Smalltalk method header that says what kinds of objects are required or permitted as arguments. However, this is offset by a helpful convention that is followed by most Smalltalkers; giving arguments a name that reflects the kind of object expected -- for example, aString, anArray, aSymbolOrArray, etc. One can argue that this doesn't reflect the role of the argument in the method, but given the small size of most methods, it's not much of a problem. Further, in application methods, many (most?) arguments are of application defined classes, rather than system-defined classes like String or Array. An argument name of anEmployee is a strong indication that an object of class Employee is required.

All this is good, but there is still a problem. Today's Smalltalk systems (take VisualWorks as an example) is loaded with all kinds of useful subsystems for doing all kinds of programming tasks. It only makes sense to want to use them to reduce the size of a project. These subsystems are organized into packages that can be loaded into an image as needed, but then which classes and which methods are part of the subsystem's API? The typical answer one hears is "Read the __code" which is not at all helpful.

This, to my mind, is a significant problem with Smalltalk today. It fails to be helpful to programmers who want to use existing subsystems by not providing adequate documentation at the subsystem level.