Sam Griffith Jr. has a nice post up on what sets Smalltalk apart:
Having experienced the joy in programming in both the Lisp and Smalltalk worlds, it is very easy to get used to the power of being able to view, inspect, browse and change everything in the system. One of these days, I hope to see the OS's that we have begin to come close to what we had in the past with Lisp machines and Smalltalk systems. Once OS's include dynamic languages in the core and expose everything as real objects that those dynamic languages can work with in a concrete way, we will be close. The power is unbelievable and allows so much. It is very great to see the current trend of the old guard of C++ and type safety starting to really embrace dynamic systems and to admit that unit testing and test-driven development really are just as stable in reality and have quicker turn-around time and more power per code unit. This brings our future closer to where those in our past have already been. Kay, McCarthy, Moon, Kaehler and all those who used and pushed dynamic languages and systems have seen and invented the future, and that future is fully dynamic.
There's much more, including some examples of using a workspace to learn Smalltalk - and introducing the Browser. All the examples use Squeak, as does this tutorial he points to. Another good introductory resource - this blog Sam pointed to. As Sam quoted from there:
I repeat: "Smalltalk is different, everythings an object. It's not file based, you can't just go around defining a function," Methods must be attached to a class (or an instance). Smalltalk is different, it's powerful, and foreign to most programmers, because most of us are file oriented and not truely object oriented. We create what is supposed to be object oriented code in a file oriented world. Smalltalk isn't that way. You add methods to real classes that are instances of a Metaclass. Your code is an object and even the text you type in when selected and inspected give an object back and you can ask the editor your using to compile the code, run it and give you back the instances, or you can select parts of the text to see what types of objects they are. 5@5 being an example. Inspect it and you'll find out it's a Point instance. Read more to see how I tried to explain that to someone confused about Squeak/Smalltalk and how I tried to help him realize that OO isn't just a language, but when taken to it's logical extent it is the environment, and everything in it
The all embracing nature of an image based environment is often difficult to get across - the development paradigm is just so different from what most people know. Something similar happens when the debugger comes up - in Smalltalk, and exception gives you the debugger, which is itself a browser. This leads to people talking past each other when discussing debugger based development - for Smalltalkers, TDD and the debugger are natural fits. In most other languages/systems, they just aren't. Since Smalltalk is so different this way, it can be very difficult to get people past the first step. Once they have that "aha!" moment, it's all good. getting there can be an adventure.