My Week With Squeak

a critique

Preamble

Before I get started, as I imagine that this may generate a fair amount of vitriol, I'd like to clarify my intent. Even after my brief experience with it, I'm really very impressed by the elegant and self-consistent model of how everything works. The "browser" metaphor for editing code is a very good one, the syntax is easy to read, and some impressive metaprogramming/metaobject hacking is possible.

In fact, given Smalltalk's history, it frustrates me greatly that it hasn't taken over the world by now; especially now that squeak, a fast and robust open-source1 implementation is available. I am interested in helping it do so; but I think that there are several basic issues that need to be resolved. Some of these are being worked on, some are not; some can't be worked on by individuals, but instead are just intended to be consciousness-raising for the community.

The Good Stuff

I downloaded the Squeak package for Linux from the main squeak site, untarred it on my Debian machine, and I was up and running in seconds! 8.4 megs seemed like a hefty download, but I'm on DSL, so it only took a minute.

The first few minutes with Morphic was what got me hooked. I right-clicked on a window, rotated it 45 degrees, and kept using it... unbelievable. Nothing I'd ever used could do that, and that sort of feature is really hard to bolt on unless the GUI is designed from the ground up to have some knowledge of itself. And Morphic is actually written in a high-level language! I tried other stuff, too -- dragging and dropping widgets out of the web browser and onto my "desktop", playing Flash animations, constructing small things out of the bits in the "supplies" tab. I even did a 'load code updates', and was impressed to see that there seemed to be some APT style functionality for managing upgrades built into the base image!

Aided by a smalltalk-savvy friend, I navigated the System Browser and Method Finder and to discover the joy of a fully reflective programming environment. Wow! I can just say "What implements this?" "What calls this?", and "What does this class look like?". I've often wished for features like that when I've worked in other environments. "Explore" blew me away yet again; being able to interactively inspect any object that's resident in memory could be *really* helpful!

After spending some time wandering around the system and trying out the various eye-popping demos, I decided to settle down and actually do some work. As an exercise to learn the language and environment, I decided to implement an IRC client (as the one in the standard distribution looked minimally functional at best).

And that's when the trouble started.

The Bad Stuff

There is no clear way to write an application in smalltalk. From the minute I understood what an "image" file was, I realized that this could be an interesting issue, but the real deep problem is that the community (or at least Squeak Central) doesn't seem to take this seriously, since it's certainly possible to create custom image files that do what you want your application to do. It seems like the attitude is that writing software that will last for more than a few months involves maintaining a fork of some version of the baseline virtual machine yourself.

In search of someone else's answer to this problem, I scoured the net for changesets, loading everything that I could. I downloaded approximately 50 changesets, and every single one either gave me a walkback upon filein or conflicted with another seemingly innocuous changeset in such a way that a basic task (opening a Browser window, or better yet, entering the debugger) would give me a walkback.

Strangely enough, there was a really positive aspect to that part of the experience. I got to use the debugger to fix up some of the simpler changesets I cared about (NewLook and SyntaxHighlighting) and it was smooth as silk; even when I was regularly nuking the debugger window by making changes to the appearance of scrollbars, the emergency evaluator let me back out my change, look at what was wrong with it, and make the appropriate fix.

Unable to find good examples externally, I turned to the applications embedded in the image. The IRC client was unusable; Celeste corrupted my image by doing something I can't understand to my fonts (and I couldn't debug it; since my default system font was set to a font consisting of nothing but asterisks, I couldn't understand any of the debug output the walkback gave me); Scamper extends its tendrils too thoroughly throughout the system for me to make sense of it, or even to figure out what is and isn't "Scamper" (String asUrl!? Object isWebBrowser?!?!).

Despite the pleasantness of the debugger, the sea of broken links, broken instructions, and broken code only gave me three conclusions to jump to:

1. The open-source segment of the squeak and smalltalk community in general is a bunch of slobs who just write broken code and expect their users to deal with it and/or fix it.
2. Nobody actually uses squeak for anything but writing the squeak VM, and it is in fact unusable for anything else.
3. It is nigh impossible to actually write and maintain a significant amount of code which stays current with the SqC image, despite many heroic efforts to the contrary; so you have to have 6 or 7 different images lying around that you can actually run squeak code.

The Ugly Stuff

One at a time, I'll substantiate those claims:

• inconsistent: Sometimes, buttons are flat rectangles (instance/?/class). Sometimes, they're shaded rectangles (as on scrollbars). Sometimes, they're rounded rectangles (in the debugger), sometimes shaded rounded rectangles (in the project navigator). Sometimes they're colored (in the "3D" world), sometimes not. Sometimes windows have titlebars, sometimes they don't (in the "3D" world).
• slow: Not only is performance chunky, but it degrades noticeably with each additional widget stacked on the screen. This is not the case with MVC, so I am pretty sure it's not an inherent limitation of Squeak. However, perceived performance could be significantly increased by addressing some of these other issues without fixing the actual performance at all.
• ugly: I suppose this is a matter of taste, but the almost-completely flat look of the interface grates on my nerves; since 1992, my user interface has given me the tactile impression of depth, and I have come to expect that. NewLook alleviates this somewhat, but all the other issues with the UI cooperate to make it seem ugly. The fact that the scrollbars do have the amount of shading that I'm comfortable with just adds an inconsistency which makes the ugliness worse.
• devoid of visual clues: Perhaps the most damning problem with Morphic; when I look at a window, I see a bunch of text separated by thick black lines, with no indication whatsoever what either the text or the lines are for. Some things are list boxes, some are editable text, some are buttons, and some are display text.
• not streamlined: The focus policy alone would be enough to make me not like using this UI. It combines the worst aspects of mouse-focus and click-to-focus. In order to focus on a window, I have to click on it; this highlights the titlebar, which is an indication of nothing useful, since my mouse needs to be in the window in order for it to have keyboard focus anyway. (I attempted to file in the window selection goodie, but it crashed my VM.) Despite the fact that almost everything has a scrollbar attached to it, buttons 4 and 5 (the mousewheel) aren't supported in X. GUI buttons are optimally positioned for carpal-tunnel -- the X is right next to the menu button in the title bar of SystemWindow (both of which are right next to the border which allows you to resize it), which requires you to be highly careful about positioning; however, the iconize button is on the right, making it necessary to have muscle memory about two different button locations. Also, things like automatic indentation and syntax highlighting are missing from the code editor. (I got syntax highlighting from elsewhere, but still haven't puzzled out automatic indentation.)
• not configurable enough: Maybe somebody likes the messed-up focus model that Morphic uses, but there ought to be at least the standard set of X window system GUI options regarding focus (mouse focus/sloppy focus/click focus) and appearance (I tried filing in the skins stuff, but it didn't work.).
• too configurable: Why isn't inboardScrollBars default? Is the 6 pixels of saved screen real estate really worth confusing everyone who's never used a smalltalk system before? Why would you ever turn smartUpdating, decorateBrowserButtons, or optionalButtons off? Also, I've twice accidentally removed a button from a window without any clear way to put it back... it seems like there ought to be some modality associated with editing/exploring the GUI vs. using it.
• buggy: Cmd-Opt-w gives a walkback. Resizing a SystemWindow so that it's really small "leaks" widgets (they go outside the bounds of the window), and there seems to be no way to set the minimum size of a window (or if there is, nothing uses it). If you resize a window or pane, the resizing rect will flicker violently until you move the mouse. Opening an IRCMorph from the "new morph" menu looks very bizarre and doesn't function. Many operations freeze the entire the entire UI (for example, the "load code updates" button would have been a killer if I weren't on DSL).
• lacking in features: There is no such thing as an "open" dialog, or a menubar, or a tabular data display widget, as far as I can tell. (of course, this could just be an artifact of the next point) The "file list" window is almost a reduction to absurdity about bad UI. The C community has Nautilus, and Smalltalk has managed to come up with this?
• poorly documented: I assume this is well known, as many of the Morphic classes have "Main comment stating the purpose..." as their class comment.

Why It's Worth it Anyway

While these problems are certainly significant, and even if the community were already 100% dedicated to fixing them, it would take a while to get to the point where they were all solved, they are at least theoretically solvable.

I don't believe that, for example, giving Python real automatic orthogonal persistence, or speeding up the interpreter by a factor of 10 to 25, is solvable in any practical timeframe. Or making C or C++ a reflective language. Squeak solves some very basic problems pretty well, and addresses issues that most other environments and languages just ignore.

However, making the virtual machine modular, adding namespaces, fixing the UI [etc] is a difficult, but eminently possible task. The problems I've enumerated here are some of the things I hope to work on as I work with Squeak.

Indeed, we're headed "back to the future", but it will take a while to get there.