What makes Squeak special?

Avidan Ackerson asked a great question:

I know that Squeak is written in Smalltalk, but are there specific advantages to Squeak over Smalltalk proper?

What makes Squeak special is the Squeak community. Fantastic history and tradition. Inspiring thinkers. Colorful ideas.

For someone used to commercial Smalltalk development, Squeak is a bit of a siren song. I've certainly felt that way. Much of Squeak's GUI wasn't built to satisfy commercial developers, but to get some wild, crazy, next generation media playground for kids and adults to experiment with. Very trippy but sometimes frustrating to someone who just wants to build a CRUD GUI.

If you want to build for the web, Squeak is a nice home for Seaside development. I'm currently using Pharo, which is still Squeak to me, but it may diverge in the near future.

Now to get a little pedantic:

Squeak is a Smalltalk. It is written in Squeak Smalltalk^[*]. Visual Works is a Smalltalk. Most of it is also written in Visual Works Smalltalk.

All Smalltalks have little variations. There is no downloadable, runnable thing called Smalltalk proper. You might call Smalltalk-80 Smalltalk proper. Squeak and VisualWorks both descend^[**] from Smalltalk-80. You might also call ANSI Smalltalk proper, but there is no implementation of Smalltalk that is only ANSI Smalltalk.

If you want to write code that you can take from one Smalltalk into another, you're in for a bit of a bumpy ride. The Seaside team probably has the most broad and most current experience here. Looking at the work they are doing for 2.9 (as well as their coding standards) are a good things to emulate.

Squeak and GNU Smalltalk are both open-source. GNU is GPL, natch. Squeak predates the OSI definition of that term and so has a more colorful license history, but it will (soon) be MIT with bits of APSL.

VisualWorks and GemStone are not open-source, but each provides professional commercial support and licenses that make it easy to start exploring and developing. VW is probably the most mainstream, commercial tool. GemStone is the leader for big Object-Oriented DBs.

Instantiations still supports VisualAge Smalltalk (formerly IBM Smalltalk). Also good commercial support.

Lots of other Smalltalks I'm leaving out.

Between Squeak and GNU, Squeak is the more traditional, image-based Smalltalk. GNU keeps its code in files, which makes sense to most non-Smalltalkers. But, as MarkusQ wrote recently:

Trying to get your head around smalltalk without using the IDE is like going to Paris and eating at McDonalds. Sure, you're in Paris, but you aren't really exposing yourself to what it's all about.

Footnotes:

[*] There are a few parts of the Virtual Machine that are written in C, but even those are actually written in a pidgin (reduced) Squeak Smalltalk called Slang. It really is a C subset with Squeak Smalltalk style. The benefit of this is you can simulate the VM using Smalltalk tools as you develop.

[**] and lore has it they may actually both still be running some of the same bits as an ancient Smalltalk image.

Seaside Community Service (Picking Up Garbage)

(OK, this post is more for my reference than to teach anything, but hopefully at least I'll learn something!)

Pharo, Squeak, and most Smalltalks have the ability to save everything you are working on when you exit the environment. This saves all of the objects you have created, any text you've written, and if your program is running, it will still be running when you restart the environment, exactly where you left off.

In Smalltalk, we call it saving the image.

Images are cool, but you really shouldn't depend on them for source code control. You should back up your program code using a separate source code control system. Examples include CVS, Subversion, and Git. Some Smalltalks can use those tools and there are certainly bridges for others, but most Smalltalkers use a version control tool written especially for Smalltalk.

In Pharo, I use Monticello. Monticello integrates nicely with the existing tools. In fact, most of the time, I don't even think that I'm using Monticello at all. I just code and when it comes time to save my code, I switch to the Monticello Browser window, click Save and type in a comment. I then save my image.

Still, it takes a bit of time to load a new image from scratch. I try to do it once a month. I know a good agile process would let me do it every day or at any moment, but I'm not there yet with my Pharo work.

Even though I'm only running a personal web server and my load is light, I'm pumping a fair bit of data from a back-end data store. I cache a lot in memory to keep my query time light. Over a few weeks of running, my image will start to grow. Today I noticed I was over 100MB! That seemed like a bit much. I'm in the 30-40MB when I load from source on top of a full set of development and web serving tools.

I went searching for a quick cleanup script and I turned up a message from Bill Schwab where he had found a Seaside FAQ with some workspace code:

WARegistry clearAllHandlers.
Smalltalk garbageCollect.

That knocked 30MB off my image.

Adrian Lienhard noted that to go further, he might want to look at SpaceTally.

SpaceTally new systemWideSpaceTally inspect.

I was about to spend some time inspecting the tally, but I noticed as soon as I ran that, another 50MB flew off. I was back under 60MB, which is my pain point.