I came across this interesting blog post talking about Seaside‘s marketing problem, and one of the comments had this to say:
It seems to me, though, that programmers are willing to put up with a lot just to get the ability to save to files and use their own editor.
For me, when it comes to Smalltalk, it’s the opposite. I’m willing to put up with a lot to get the Smalltalk language. And then, after a little bit of “putting up with”, it turns out that there’s nothing to put with anyway. The Squeak Refactoring Browser with Shout and eCompletion pretty much does everything I want in an IDE, and Monticello handles the version control in a way that’s so simple it just works – at least for my purposes, I haven’t seen how well it works for large teams.
The biggest problem most people starting Smalltalk seem to have, is getting past the need to have a file that they save to disk, check in to version control, and run a compiler over. But that’s an artificial need, the only reason you want to use your own editor and save to disk is because that’s how you’ve _had_ to do it in the past.
There’s really nothing scary about working in the image – particularly when you’re using a source control system like Monticello (and I’m sure the experience is similar when using Store on VisualWorks).
You have your base development image, which is like your IDE with no files loaded, you create a new Package in Monticello and associate the repository you want to use with it (which is just a directory – either local, or on an FTP or WebDAV server for example).
Then you start writing your code.
That’s all there is to it. You check in at logical points just like you would if you were writing in C or Java and using Subversion or CVS.
You can test your code right in the image, just like you can test your code right in a traditional IDE, and if you want to try it in a dedicated testing environment, you’d just take a base image you’d configured with your testing or production needs, and install your code using Monticello or MCInstaller.
Even if you weren’t using Monticello, you could always file-out from your dev image and file-in to your testing or production image.
The process becomes so much easier when you stop worrying about what’s different about Smalltalk, and think about what’s the same instead.
If you enjoyed this article, please consider sharing it!
That was my comment you quoted. :) What you describe is the way I approached Squeak as well. I wanted to use the Smalltalk language, and was willing to put up with the lack of easy to find documentation to use it. You can find it, but you have to work at it, or buy it in some cases. It was frustrating at first, but it just took time, and unlearning some previous patterns of work, as you said. Now I’d like to use it more for what I do every day. I haven’t found a way to do that yet, but I hope I will someday.