Do i really need to use the ide to 'get' smalltalk? I'm pretty happy with my tools, and would only use ST for the paradigm shift anyway. I don't want to leave my text editor. It has become a part of me, and i can't imagine life without it.
It's tagline is "The Smalltalk for those who can type".
However it doesn't look very lively, and you'd be pretty lonely. I don't know any projects using GNU ST. Squeak, and now Pharo, are really the only implementations with momentum right now.
And as far as the typing thing... I am a die-hard Emacs user, and I still enjoy Pharo. This is because programming in Smalltalk is not so much about writing and editing code as it is working with objects. And, frankly, Smalltalk's way of working with objects (and remember: classes and their methods are just objects) is much more powerful than the average editor's way of working with source code.
(I'm basing this on the code for SmalltalkHub, which at least used to be available on SmalltalkHub, and which had Pharoisms in the code base. It's entirely possible they simply moved those pieces over to GNU Smalltalk, though.)
The two problems I have with it are simply that it's far slower than Pharo or Squeak, and that using the GPL for a Smalltalk makes me extremely nervous, since the concept of a derivative work gets really dicey when any half-decent Smalltalk app is going to end up throwing new methods into the base library.
To the best of my knowledge, there exists no faster environment to think and code in. SLIME come close, but it's too textual and doesn't seem as fast.
It has nothing to do with how reliable smalltalk is. With such an alien paradigm I'm sure I'll screw up and lose code somewhere and have no way of knowing how it happened.
Perhaps putting code in a binary image has also hindered the spread of smalltalk? I see fewer code fragments of smalltalk than I do of say lisp. (I'd love pointers to more smalltalk code reading.)
The image is just bytecode and a bunch of predefined objects. So where does your source code live? Inside of a file called YourImageName.changes, which contains every single line of Smalltalk you execute, including everything from class definitions to method renames to one-offs in workspaces and so on.
If you blow up your image, you simply start with a new one, open a change sorter on your old .changes file, and file in the exact pieces you want, skipping over the part where you, say, accidentally did "Integer become: Boolean" or something equally stupid.
So far, so good: your code is indeed in text, and it's always up-to-date, and it's trivially machine parsable. So what's the issue?
The issue, for me, is that there isn't, by default, a dump of code that represents your program as it exists right now. With that trivial change, using traditional source-control becomes a royal pain the ass, if not outright impossible. That's why you see almost zero Smalltalk code on sites like GitHub, even though the community's active: they end up developing their own systems, such as Monticello, and their own hosting solutions, like SqueakSource and SmalltalkHub, that work with Smalltalk .changes files, rather than Smalltalk code living in text files.
If Smalltalk made one-file-per-class, or something similar, the default, and if it automatically generated "compacted" changes on a regular basis (basically a .changes with all of the stuff you deleted thrown out--in other languages, you'd call these the source files), then I think it'd go a long way to helping adoption. Hell, as a side-benefit, writing Smalltalk code in Emacs would be a lot easier, for those who like that particular path. But in the meantime, that's the way things work.
If everything is in file xyz.changes, and the file is trivially parsable, could you write a program to parse the file, replay the changes up to time T, and dump out a textual representation of the program as it existed at T?
I get that this isn't the Smalltalk way. Typically it's best to approach a system on its own terms. Ideas like this are probably the equivalent of a newcomer to Lisp trying to "improve" things by getting rid of the parens. I'm just curious about what the technical barriers to doing such a thing would be.
But at the same time, this meant that collaboration between users was hard, and that people were locked out of their favorite editors and VCSs.
Much of the power of Smalltalk comes from the environment. It is pretty amazing how even now parts of Smalltalk are more sophisticated than todays programming tools.
Dan Ingalls: "An operating system is a collection of things that don't fit into a language. There shouldn't be one." http://www.cs.virginia.edu/~evans/cs655/readings/smalltalk.h...
Alan Kay mentions this idea in relation to Lisp and Smalltalk: http://www.youtube.com/watch?v=tQg4LquY0uU (It's buried somewhere after 24 minutes.)
This is part of the paradigm shift!
That means that you'll be spending a fair bit of your time editing, which means that you'll want the ability to use your editor of choice, rather than being forced to use someone else's editor of choice.
This has follow-on effects: refactoring, TDD and patterns are so much easier when the code resides in tiny snippets.
It's a whole new world, where the code is 'live' rather than merely contained in static 'dead' text files...
Use the tools you are used to, use the language that is super productive and run the result on the JVM.