BUT we know that we are not there yet. Squeak is not approachable yet by non-computer users, it is full of inconsistencies and convoluted and redundant code, frequently devoid of any comment or useful organization, and it is bulky and it is slow.
So what we're about, while in the process of doing other useful things for the Mouse, is cleaning up what's messy, speeding up what's slow, simplifying what is overly complex, and working to make the whole thing accessible by end users.
It's a long process, but we're not in a hurry. We've been at this for a while, and we want to get it right this time. Meanwhile it's the best system we know of for doing what we do, and this is a wonderful community for sharing what we and you are doing to clean up the kernel, and explore the possibilities at the periphery.
- Dan, for the Squeak Team
The forces in the pink plane have to do with making an ever-better Smalltalk-80 system that can serve a wide spectrum of research and academic needs, while leveraging off the large body of ST-80 documentation, existing code archives, and synergy with high-performance industrial ST-80 systems. In this plane Squeak's high level of compatibility with the ST-80 language (and even with the MVC display architecture) is a plus, and the current forces of progress are aimed at a higher performance interpreter, with support for block closures, exception handling, as well as some answer to various needs for finalization. There is an active crew, led by Ian Piumarta, working on the first two items, and we are holding a couple of solutions to the latter issues in abeyance until the new interpreter is incorporated and running stably.
The forces in the blue plane have to do with a completely different graphics model, evolution of the language model, and hopefully an even simpler yet more powerful language kernel. Each of these constitutes significant change, and is thus at odds with various entrenched interests. At the same time we feel that each offers significant benefits. A fair portion of the new graphics model, based on the Morphic interface to Self is already running and can be explored in the Play With Me windows of the release. While some parts of Morphic have not been honed to peak performance like other parts of the system, many are much simpler and yet more general. With the next release you will see presentation graphics support such as drop shadows and gradient fills, as well as desktop publishing capabilities including linked text frames, text flow inside and around arbitrary shapes, and letter kerning.
To best understand the "blue" pulls within the Squeak group, you need to understand what we're after. Our number one commitment is to an exquisite personal comuputing environment. Imagine a system as immediate and tactile as a sketch pad, in which you can effortlessly mingle writing, drawing, painting, and all of the structured leverage of computer science. Moverover imagine that every aspect of that system is described in itself and equally amenable to examination and composition. Perhaps this system also extends out over the Internet, including and leveraging off the work of others. You get the idea -- it's the Holy Grail of computer science. All and everything. So if some new approach comes along that takes us closer to that ideal, but at the cost of a break with ST-80 tradition, we will probably take the new approach.
Remember that I said "personal" computing environment. This has lots of ramifications. One aspect is that things must stay small and simple enough that they remain comprehensible and accessible to a single person. One approach to desktop publishing would be to somehow intertwine Squeak with Microsoft Word through ActiveX (it's easy: just use what's there and order three sets of manuals each six inches high ;-). Our approach, on the other hand, is to do it all from scratch in Squeak, simply and generally, possibly omitting some features, but ending up with something that most folks on the Squeak list could understand, and that serves most of our needs. Another of the "personal" aspects of this approach is that the end result is independent of Microsoft and Intel -- it can be ported to any of the bare chips from Acorn, Hitachi or Mitsubishi (that go for $10-$20 a pop) with nothing but a BIOS.
We are currently experiencing two forces on the language itself, one from attempts to design a computing environment for children that can grow seamlessly into the full Squeak environment, and the other from an age old desire to somehow refactor the kernel into a dozen or so classes, with a dozen or so messages each.
We are also aware of the present limited state of documentation of Squeak. We do not feel that existing ST-80 texts are the answer to this. Instead, we want to upgrade our tools for documentation, so that the entire system can be read from within itself as an "active essay" with hypertext links and embedded executable examples to explore.
This, of course, is all apple pie and motherhood, so here is an entirely practical answer to the question of where Squeak will go in the next six months. [And, of course we can only answer for the Squeak team and the system that we support. Things are heating up outside our group, and you might well see Squeak variants focussed on Windows native widgets, or Gemstone-style databases by the end of this period.] It is our intent to put out a new release (probably dubbed 1.3) sometime in January '98. We hope that this will include most of the new interpreter work so that it will be shaken down by wide usage, and so that experiments with further performance gains are easy to do within that release. That release will also include the additions to Morphic that are mentioned above, as well as several improvements to music support, and a first run at crosslinked internal documentation.
In the same time frame, the Squeak team plans to be working entirely in Morphic, so we will be exercising our optimization skills on getting the performance there up to the same level we see in the MVC (Models, Views, and Controllers) browsers. With the next release, probably in March or April, you should be able to jettison MVC, in just the same way that you can now jettison Morphic if you want to save space. We hope to be fairly far along with interpreter tuning by that time, so that the overall system speed would have picked up a factor of two or so over what we have now. We hope to see a couple of web-based tutorials that you could click on in the startup image, and that would take you through the whole of Squeak with lots of executable examples along the way. We see the Squeak of six months out as being wonderful fun to play with, or to give a presentation from, on a good pen computer.
You will probably also see an answer to basic exception handling and finalization by then, as well as some language experiments. A favorite of ours is type inference, and we would like to see Squeak be adequately reflective by that time that if it looked at its navel for long enough it could tell you the types of every variable in the system. You will probably see some experiments in other syntax and language features, but within this time frame, we don't see any compelling reason to drop the common language synergy that is working so well right now.
Of course none of this may turn out to be true. We'll feel good if we can just keep doing fun stuff and sharing it with our fellow Squeakers.