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-source{1} 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:

  * 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.

  * Nobody actually uses squeak for anything but writing the squeak VM, 
    and it is in fact unusable for anything else.

  * 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. Various 
    things about my investigations into the squeak community show me that 
    conclusion number 3 is probably the true one, but I could easily see a 
    frustrated, but slightly less curious person than I in the same 
    situation jump to 1 or 2, and go back to their previous language of 
    choice. It is my sincere hope that the Stable Squeak project will fix 
    this, and make most of this little rant invalid in 2 months time. :)

The Ugly Stuff

Although my initial impression of Morphic was "wow, neato!", trying to 
work with and code to it was a disillusioning experience. It manages to 
combine the worst aspects of every UI I've ever used; it is inconsistent, 
slow, ugly, devoid of visual cues, not streamlined, at once not 
configurable enough and too configurable, buggy, lacking in features, and 
poorly documented.

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