I think it's a shame that so few people these days know what a smalltalk development environment looks and feels like. There is no distinction between learning and experimenting. It's all part of the same feedback loop. It's a shame that almost no modern programming language these days provides the same kind of workflow. If they did I think the author would have a different take on learning and experimenting all in one go instead of segmenting things the way he did.
Fifteen years ago, we had people who felt the same way about Smalltalk, so they wrote a major enterprise system around it. Many other groups in our organization came to rely on these central services, so strange things were done to make it scale.
Smalltalk was supposed to be a teaching language - pick an enterprise stack when you want to build something serious, but go ahead an learn on Smalltalk, Forth, Lisp, etc. Understanding other programming languages (especially when they're using different "types" - functional, declarative, imperative) will make you a better programmer.
> If they did I think the author would have a different take on learning and experimenting all in one go instead of segmenting things the way he did.
A little surprising given that the author seems to have experience with Clojure. Lisps have a line between learning and experimenting quite blurred as well, though Clojure is probably not as far into this as Common Lisp or Scheme.
It's just a vague recollection now. I wouldn't be able to do it justice. It's one of those things that doesn't translate well into words anyway. The best thing you can do is download Pharo Smalltalk and start playing: http://pharo.org/.
