=== Top of the Swiki === Attachments ===

The Future of Squeak

{see also: TripReports, Place in the Universe, The History of Squeak, and previous versions of this page here: Looking at our Future}

Where is Squeak Headed?

It has been a year now since we have written on the topic of where we see Squeak heading. It is both refreshing and alarming to revisit this topic at yearly intervals. On the one hand it is gratifying to see what we have accomplished that we had planned, and exciting to see what has emerged from serendipity as well. On the other hand it's sometimes scary to see how long it takes to make progress on our higher goals -- the "basic science" of this project.

Looking back, 1999 has been a pretty good year for Squeak. Consider the following, where is the future, year 1999 is going to be over!


This year has seen the development of Balloon, a completely new rendering engine offering anti-aliased rendering of resolution-independent outline graphics in all color depths at high performance with no reliance on additional hardware support. Add to this an entire layer for 3D rendering, and support for Flash, TrueType and VRML standard formats. Recently the 3D engine has been integrated with morphic to allow projection of morphic canvases on surfaces in 3D.

Sound and Music:

We now have wavelet analysis, high-speed ADPCM codec and a high-speed FFT. The latter is built into a real-time waveform and spectrum analyzer. Sound recording has been embellished with the ability to loop sampled sounds, and to play them immediately from a keyboard. Looped sampled sounds generally expand Squeaks ability to produce high quality synthesized music. Cut, paste and minor editing features are now available in the PianoRoll score display.

Squeak Performance:

The underlying bytecode engine has been accelerated by around 25%, and a prototype Jitter II demonstrated nearly a factor of two over this speed using platform-independent threaded code.


Continued evolution of Squeak's tile scripting and viewing system has incorporated multipanel viewers, and multiple categories for slots and scripts. Also the ability to remove and rename both slots and scripts, and extensions to the scripting and triggering vocabularies. "Paths" can now be created by direct manipulation, and invoked by script or menu. End-user features have generally benefitted from increasingly pervasive "help" cues.

General Enhancements:

The Morphic screen model has been extended with Flaps. These can be local to a project or global, and their behavior may be tailored in numerous ways. A new Preferences panel and window appearance control have made some of Squeak's inherent flexibility more accessible. Drag-and-drop access to parts bins and trash have simplified work with presentation graphics and morphic constructions in general.

Our once-primitive event recorder has grown to incorporate voice-over with compressed speech, and can record and play back sessions across mulitple project boundaries. A quiet contribution, hailed on comp.lang.smalltalk as "brilliant", Squeak's new SelectorFinder can magically find and display a method if you simply give an example of what it does.

A number of enhancements have come to Squeak entirely from our internet community. These include postscript output from morphic canvases (including justified text!), a structured object explorer, an ANSI-compliant exception-handling mechanism, and a primitive compiler with an example interface to AppleScript. Countless other valuable enhancements have been posted on the Squeak mailing list.

The Future

Looking forward, we have some specific goals in the near term and some more general goals farther out. To follow the foregoing arbitrary categories...


We have learned from the first year of Balloon, and hope to produce two major new releases. One will be a complete rework of the rendering engine with a more effective approach to anti-aliasing, and hopefully improved handling of thick lines. The other will be a layer to provide enhanced performance through hardware acceleration when available.

Sound and Music:

For speech, we would like to explore simple recognition and synthesis capabilites, along with improved compression. For music, an active goal is to develop more compact high-quality timbres, or possibly to leverage off some of the existing industry standards in this area.

Squeak Performance:

While Moore's Law continues to answer many of our needs for higher performance, we still hope to provide an optional VM that delivers between two and four times the current level of Squeak performance. Not only would this help to address various real-time challenges, but it would also minimize the need to embed kernel features in less malleable primitive code.


We hope in the coming year to make the bridge between scratch programs (do-its) and full methods, and between the simple world of tile scripts and the full Squeak syntax and control structures. We also hope to extend the existing support for method triggers into a general architecture for events, control structures and undo facilities. The Wonderland 3-D examples have enriched our view of what an end-user system should provide.

General Enhancements:

We have just assembled a number of relatively independent changes into a gestalt that we hope will enhance the modularity of Squeak and its fitness for a number of network applications. First we implemented ImageSegments, a facility that can identify and write to a binary file any set of objects pointed to solely by a set of root objects. Then we made WorldMoprhs be the same as PasteUpMorphs so that any world can behave as a book page or playfield or similar past-up construction. Then we made it possible to write these "SqueakPages" out to a server as external objects, using SmartReferenceStream. Recently we succeeded in swapping out entire projects -- ie morphic worlds -- as image segments and having them reloaded on demand.

We now foresee the possibility of an extended universe of Squeak worlds, distributed over the internet as web pages, downloaded and internalized via SmartReferenceStreams, and swappable in a reasonable memory footprint by ImageSegments. The Squeak kernel could remain small -- 5MB or less, yet it would have access to the entire universe of possible extensions. Users could send segments to each other, or store segments back to servers in export format, in the manner of multimedia swikis.

We plan to add a simple nested global address space to Projects and then to release a number of applets, along the lines of the Play-With-Me demos, in this framework. While it may not be the most general possible name space solution, it should nonetheless provide an architecture capable of hosting numerous reasonably modular networked extensions to the Squeak computing environment.

The remaining things we hope to accomplish in the coming year are less specific, but they will be driven by creating and evolving active content in the new web-based architecture. If we can make it easier for media authors in general (ie non-hackers) to contribute, the Squeak community will grow to embrace contributions that are not just about Squeak, but that are more generally enlightening and educational, enabled by Squeak.

Dan Ingalls, for Squeak Central

PS: We have refered in the past to "Basic Squeak" an attempt to re-simplify the essence of Squeak and revive the ideal of a general and powerful system that is nonetheless approachable by novices. While this project is still near the top of our priorities, it is (obviously ;-) on hold at this time. Our feeling is that we still need to extend our reach as we are doing with scripting and the e-toy environment, and try out a number of end-user applications in a web-based architecture, before we will really know what the kernel should be and how it wants to be seen by users. As we have said when people groan about code bloat in Squeak, "It's going to get worse before it gets better." But it WILL get better.