[squeak-dev] Smalltalk for small projects only?

mkobetic at gmail.com mkobetic at gmail.com
Sun Jan 29 00:38:27 UTC 2012


"Janko Mivšek"<janko.mivsek at eranova.si> wrote:
> Ralph Johnson in his InfoQ interview made an interesting observation:
> 
> 2:55 minute: "Smalltalk made an fundamental error ... image ... you can
> build something with 4-5 people what 50 people can build in Java, but if
> you take 200 people in Java ... it is really designed for small systems
> ...  "
> 
> Are we because of the image really destined for relatively small
> projects and small systems (of Java 50 people project size)?

The "image" argument is one of the easiest to pick when you want to justify your xenophobic reaction to an unfamiliar environment you're about to enter ("... but they are green and have antennas...", never mind that the antennas may actually be useful for something). But there's nothing fundamental about Smalltalk that requires an image, c.f. there are a few Smalltalks that don't make you use one (e.g. Smalltalk/X). It's just frozen state, many IDEs and editors allow you to freeze their state (e.g. Eclipse workspace), it would be a royal pain having to reopen the files you were working on manually every time, wouldn't it.

I think the problem is that most newbies, when being introduced to Smalltalk, are immediately confronted with "the image" as if it was something fundamental, like they couldn't get any further until they grok it. But there's nothing preventing you from never saving the image. Just commit your source code (and it could just as easily be a common file based VC in the back there) and quit the image. Always start from a fresh one and load the code back in. In this mode there's (superficially*) no difference between Smalltalk and any other IDE, you write your code, you run it, debug it, commit it, etc. You can completely forget the image if you want, it's just that most seasoned smalltalkers (the ones doing the introduction) have learned to take advantage of the image and using it in all kinds of creative ways, so they want to pass the knowledge along and manage to freak the newbies out in the process.

(*) the real difference between Smalltalk and other IDEs, that may or may not be an issue in any particular case, is that the IDE runs in the same memory space using the same code base as the application, so your development can crash the IDE, while other IDEs prefer to crash on their own :-).

But I disagree that the image is some sort of technical obstacle to scalability, I think it's completely orthogonal. The only place where it's hard to ignore the image with the image based Smallltalks is deployment. At this stage the image is the "compiled object code", in the same sense that a shared library is "compiled object code". You can (and some do) deploy as a clean base image, load the application code on start and launch the application. That's no different from a java or python app, their base image is just burned into the VM. But it's so much easier to make that snapshot when all of this is finally loaded in memory and ready to run. It loads faster, there are no scattered files to hunt down in the dark corners of the filesystem, makes perfect sense in many (most?) cases. If people are freaked out that they don't need to mess with CLASS_PATH, or PYTHONPATH or what have you, well, it would be quite easy to "fix that", wouldn't it.

You could say that every piece of software "has an image". When it is loaded it initializes its runtime structures, lays them out in memory and starts running. Nothing fundamentally different from the base image case, the "image" is just burned into the executable. If the VM was simply embedded in every saved smalltalk image and the resulting file was turned into an executable, you can't really tell the difference. The image just wouldn't be portable anymore.

So I could agree that the image can be an obstacle to adoption if you rub it in people's face, but it can just as easily be mostly ignored. It's not significant unless you make it so in your development process.


More information about the Squeak-dev mailing list