The self-reflective and late-binding nature of Smalltalk allows you to create views that are more de-coupled from their models. For example, when a textbox sends #getText to its model, it doesn't care what the model is, as long as it can respond to getText -- you can even swap the model at run-time, and as long as the message is answerable, it all works. Olsen contrasts this with C/C++ where the compiler requires the model and view to be linked together at compile time, the types have to match, etc.
I have to relate an anecdote from the early days. We were using Smalltalk-76, the first Smalltalk that performed well enough to support serious software (it had the same engine as Smalltalk-80, and a simpler body ;-).
There was a student (I can't remember who this was) on one of the Alto's in the corridor who was having fun implementing a Fraction class (there wasn't one built in). He came over and asked me to give him some help because he had gotten things in such a shape that something was preventing the screen from redisplaying successfully when he proceeded from the debugger.
I went over and started to paw around, and discovered fairly soon that the bottom-level call on BitBlt was recieving Fractions as parameters, and was therefore failing. As I looked around to see how that happened, I was astounded to find that the entire browser in question had fractions in practically every point and rectangle in all its views and subviews. I asked him about this, and he said, "I just reframed it, but maybe it was because I made divide return a fraction." I said, "Hmm, maybe so. What do you send to a Fraction to get the integer part?" He told me. I added the coercion to BitBlt's fail code, and the whole thing proceeded to run just fine when I restarted the method. I remember feeling almost dizzy on the way back to my office.
- D