Are we killing Squeak?
And I mean literally killing - making a system that is essentially alive essentially dead.
Smalltalk, being image-based, has one property that makes it different from superficially similar systems (like, say, Ruby with an IDE) - it is a living collection of objects (or ducks, or turtles, whatever the word du jour for them things is). A typical other piece of software starts out as dead code, which is briefly kicked into action, it runs, and it dies again. Smalltalk, on the contrary, always runs. At best, it is suspended in an on-disk image.
The best way to describe how Smalltalk works is to compare it to what is known in the US as Amish Friendship Bread (and known under various different names in other parts of the world). Smalltalk objects never die, they are passed on, alive and kicking but in a suspended animation, between Smalltalk developers in the form of an image. When you de-hibernate the image, you have a full, living, complex ecosystem of objects in front of you. The lineage of a Squeak image goes back certainly to Squeak version 1, probably to Smalltalk-80 (over 25 years old), and maybe even to Smalltalk-78. There’s quite a bit of living history in there…
Another analogy I often dig up is that how biological living systems work. DNA is more similar than different between living species (with us sharing the vast majority of our genome with the other members of the Hominidae family), and most of the difference between species is made by tweaks here and there, relatively minor compared to the whole of the genome. Similarly, a Smalltalk application typicallly is created by adding code, modifying code, but also by leaving most of the code in tact.
It turns out that this living system gives some unique powers. You can interact with it, inspect it, development is by nature incremental (because you never start with a blank slate where you start writing new code, you always start by modifying a living system), and personally I think it is a major reason for Smalltalk’s power. Therefore I also think that “Smalltalk script languages”, which attempt to mimick Python or Ruby, are not a very useful idea.
Lately, in Squeak, we have tried to tame the beast by applying good old software engineering to it. Basically, we’ve been trying to chop up the image in packages, in order to remove bottlenecks in further development, but the process has been akin to extracting the eggs from a cake. Quite painful, people responsible for Squeak 3.9 have spent inordinate amounts of time, and my feeling is (correct me if I’m wrong) that no-one is really happy with the end result. And certainly not with the process.
So, I’ve been wondering. Is dissecting our living friend, the Squeak image, into packages a fruitful path into the future? I don’t want to stretch analogies too far, but usually if you dissect something, you kill it - that makes one think.
Well, I can’t pose these questions without a solution, of course. Here is just a short outline of an idea that might provoke some discussion - if anything, it’s always good to evaluate radical alternatives to what lots of the Squeak community (including me) have been advocating as the way to move forward.
The problem any solution needs to solve is that of bottlenecks. Remember, a major reason for starting taking Squeak apart was that we previously has one or two people with access to the “update stream”, and they had to sift through all the patches for all the various bits and pieces in Squeak. Also, we want to make sure that when Squeak forks, changes to common code can be shared between the forks without introducing bugs.
I propose that any Squeak fork (I will from here just say “Squeak” if I mean the ‘community Squeak’ / ’squeak-dev’ version) has a mother image, with a web-accessible browser. That’s all, basically. Here’s the detailed outline:
- Committers get access to the code browser. So they can directly edit code (preferably not, of course
), load patches/changesets, and run unit tests; - Everytime the full test suite runs all green, the image snapshots itself to a publicly accessible repository. Also, changesets since the last snapshot are filed out so people can do incremental updates;
- There’s a self-selected seed set of committers, new committers need three recommendations and no vetos.
Ok, skimpy on the details but I think you get the gist of this proposal: to cooperatively evolve a live system, instead of make Squeak succumb to classical software engineering by killing it first.
I’m interested to hear your comments
Stumble it!
Post to del.icio.us
September 22nd, 2006 at 2:57 pm
Another nice things to have would be something more advanced than packages to collect common functions (ie. subviews on the whole bag of classes). monticello goes in the right direction by doing package + extensions in its browser, but often, more than one such package is necessary.
(this would also help with stripping images for specialized purposes - ¨I’d like to keep everything that’s in this view, and its dependencies - remove everything else¨)
the other thing is namespaces - such a model of an unsplit living image will (and should imho) lead to an image with lots of projects inside. Eventually, it’ll become hard to choose a class name that’s short, descriptive, to the point and doesn’t clash with another class of another project that does something entirely different.
I think spoon is resistant to that (as it uses internal ids for lots of things), but I’m not sure how that would fit in a living image model…
September 22nd, 2006 at 2:57 pm
Too continue the analogy: “It is not the strongest of the species that will survive, or the most intelligent. It is the one most adaptable to change.” - Darwin
I think this is why squeak needs some sort of module system. In my mind, it is about managing dependencies, good old low coupling, high cohesion. I tend to work from the naive assumption that this will make a more adaptable system. The easier we can drop and add packages the better off we will be.
I like the idea you outlined at the end of your post. I think it is independent of packages though. Would a continuous integration (CI) server achieve the same effect? Or is there a subtlety that I’m missing here?
I’m imagining a server that takes in change set or mcz’s applies them to the image, runs the test, if they pass commit to the main repository, else rollback changes. I haven’t thought it all the way through, so I’m sure there are some gotchas, but I think you’ll get the basic idea.
September 22nd, 2006 at 3:50 pm
The problem with .mcz’s is that they deal with (dead) code, not with (live) object constellations. That’s the whole issue…
September 22nd, 2006 at 7:25 pm
As I was reading your article I was thinking of Spoon because it deals with “live” rather than “dead” code and it is highly adaptable by its very nature. But am not sure of the details of how it would fit into the scheme of things quite yet though…
September 22nd, 2006 at 11:26 pm
Hmm… Are you thinking in terms of a distributed scm system (such as Darcs, Mercurial, etc.)? Or implementing the equivalent directly into Squeak?
September 23rd, 2006 at 8:56 am
Well, MC is distributed enough for me. The issue is - it is only a code management system. To pull out my analogy again, it is akin to having a DNA library when what you really want to do, maybe, is to grow a garden…
September 23rd, 2006 at 12:02 pm
Squeak is full of shit.
I can write failing tests for all the major packages, compiler, decompiler, collections, io, kernel (blocks), you name it. And they are not gonna fixed soon.
Having the full test suite green is only possible by removing failing tests and not including tests of bugs reported at mantis.
September 23rd, 2006 at 3:55 pm
“Similarly, a Smalltalk application typicallly is created by adding code, modifying code, but also by leaving most of the code in tact.”
I’d claim that’s only the case because the cost of taking out gobs of unused code has been so high.
In “a full, living, complex ecosystem” in Nature, when critters come together they sometimes kill each other, and sometimes kill the ecosystem. That’s a problem in our “full, living, complex ecosystem of objects” - when we introduce new stuff, the new behaviours are sometimes incompatible and kill the ecosystem.
We get to play Zoo Keeper - we get to invent ways to package behaviours that would be incomprehensible in Nature.
Like classboxes
www.iam.unibe.ch/~scg/Archive/Papers/Berg03aClassboxes.pdf
October 3rd, 2006 at 4:13 pm
Squeak is already split into many pieces, just not along the dimension I would like to see: there are many images (a dozen or more just on this machine’s disk!). An alternative would be to have a single world wide image built up from separate chunks of living objects in such a way that there could be multiple viewpoints (not necessarily mutually compatible) of the whole evolving thing existing at the same time.
October 5th, 2006 at 1:01 am
I’m glad somebody is asking these questions. I can only talk about Squeak as a user at this point, not as an experienced Smalltalk developer, though I have some software engineering experience.
I was just asking Mark Guzdial about his book “Squeak: Open Personal Computing and Multimedia” last week. I asked if he was going to write an updated edition, since his book was written for Version 2.9. The response I got back from him was forlorn. He said no updated edition was planned, but he attributed this more to it not selling well. He was also critical of the team in charge of Squeak now:
“The current version is quite disappointing. It’s been taken over by a pure software engineering group, so music synthesis (for example) no longer works. They just don’t care to keep it going.”
Does that sound like Squeak is being killed? I’d have to say yes, at least for the educational community. I have not been hearing these complaints from Seaside developers, for example.
I asked Guzdial what’s the most recent version he would recommend. He said 3.2.
It’s striking to me that updated versions, which have been marked “stable”, have features that are broken that used to work. This is just my impression, but it’s sounding like the team has unintentionally forked it already, since it looks like multimedia has gotten “the shaft” in the more recent releases. I’m not saying this was necessarily done intentionally. I’m just describing the effect.
IMO, from a user perspective this is not good. This gets into perceptions. I was drawn to Squeak because of the screencasts I’ve seen of Alan Kay demonstrating it. They’re a few years old, but his focus was on Squeak being an educational tool, that students could use it to conduct experiments, manipulate graphics, video, sound, etc. Since it’s sounding like these aspects are starting to break, I imagine it’s alienating that community. I think that’s sad, because I think Squeak had real potential there.
For me personally, I’m interested in the multimedia aspects, just for the fun of it, but the real draw for me was Seaside.
On the engineering side, just a guess, it sounds like it all comes down to detecting dependencies. With everything being an object, would it not be possible to write a utility that shows what other objects are dependent on an object that is being modified, or removed? Once you can see these dependencies, would it not help in making intelligent decisions about what to do?
My impression is that working on Squeak at fundamental levels is like working on an operating system. It’s very complicated work–very easy to break things you didn’t intend to break.
I sincerely wish you the best in your efforts. Asking these questions shows that you DO care, contrary to what Guzdial said. I guess if I could make one request it would be that you be MUCH more careful about how you label versions. Only label a version “stable” when it appears to be such from all aspects.
October 6th, 2006 at 5:57 am
I’ve been using Squeak off and on since 1.x days; I even more or less lived in an image for a while (email, etc). Not so much now days.
Squeak is increasingly forgetting about objects and becomming obsessed with code. And it is staggeringly good at code - development is brilliant.
But although there are a million sophisticated ways to file in, manipulate, research and run code, there are no standard ways to deal with music, photos, or even non-code text.
What Squeak could easily be: www.omnigroup.com/applications/omnioutliner/ www.apple.com/itunes/ www.devon-technologies.com/products/devonthink/ www.apple.com/ilife/iphoto/
What Squeak seems to want to be: www.eclipse.org/
October 11th, 2006 at 1:41 am
[…] Cees’ blog - Written by Achter de Kamp. Apparently he’s one of the people on the Squeak development team. He wrote a salient post recently called “Are We Killing Squeak?” […]
October 13th, 2006 at 3:35 am
[…] – [0] See this blog entry by Cees de Grot for an enthralling account of Smalltalk’s lifeliness. […]
March 12th, 2007 at 9:33 pm
I think Squeak will evolve in that biological way only the day it have the possibility to model biology in an adecuate scale. For that it should has to have no image at all. It should has to have only a virtual environment of virtual objects scaling not to hundreds thounsands but to hundred trillon virtual objects. To say it in short: an environment of living objects in disk.
Even then, the biological analogy will be “so analogical” that the image can easily get sick as any soma can get.
So I answer with a new question:
we can have a squeak that works on disk without scale problems?