| |
| |
| |
| |
What is Squeak's place in the universe? There's so much activity on the Squeak list, I wonder: "How is Squeak really important?" I sense incredible momentum and potential but I can't tell if it is mainly related to growing Smalltalk into the next great thing or if it is about creating a great tool for building actual systems. How does Squeak relate to commercial Smalltalks? Does it intend to become better than the best commercial implementation, like I've read Linux has to commercial Unix? Or is it more like an excellent experimental tool for working years out in the future of language design?
How is Squeak important? Squeak extends the fundamental Smalltalk philosophy of complete openness – where everything is available to see, understand, modify, and extend for whatever purpose – to include even the VM. It is a genuine, complete, compact, efficient Smalltalk-80 environment (*not* a toy). It is not specialized for any particular hardware/OS platform. Porting is easy – you are not fighting entrenched platform/OS dependencies to move to a new system or configuration. It has essentially been put into the public domain - greatly broadening potential interest, and potential applications. The core team behind Squeak includes Dan Ingalls, Alan Kay, Ted Kaehler, John Maloney, and Scott Wallace. All of this has attracted many of the best and most experienced Smalltalk programmers and implementers in the world.
But Squeak and the thrust of most Squeakers' efforts are at a bit of an angle to that of commercial systems. Many of us have a stock of strange ideas and peculiar notions we have accumulated through the years that are either impractical or impossible to implement in commercial Smalltalk environments and no suitable alternative existed until Squeak. Desirable things that bring Squeak more in line with "modern" Smalltalks include blocks as true closures, block local variables, an event-oriented VM, namespaces, dynamic code generation, etc. But these must be tempered by the desire to maintain the approachability and portability Squeak now enjoys. Greatly increasing implementation complexity to double performance, for example, is a bad tradeoff. And the need exists to fit Squeak into limited hardware. Code bloat is not an option.
Growing Squeak toward the next great thing and creating a great tool for building real systems are not mutually exclusive goals. Increasing the modularity and encapsulation of the Squeak environment, adding the ability to deal with multiple images and do remote debugging, handling tethered objects, orthogonal persistence, etc., will all contribute to building real systems. – Dwight Hughes
The query also elicited these ?? comments about Squeak's destiny as seen by one of the Squeak team:
Thanks for your candid inquiry about Squeak's destiny. You must know from the various messages on this list that Squeak's future is at best a wavefunction. However, as one of the founders, I feel it still somewhat incumbent upon me to answer your question. Also, since it has been a while since we've said what we're up to, it seemed a good time for an update.
Squeak began, very simply, with the needs of a research group at Apple. We wanted a system as expressive and immediate as Smalltalk to pursue various application goals: prototypical educational software, user interface experiments, and (let's be honest) another run at the Dynabook fence. As we tell in the OOPSLA / Splash paper "Back to the Future", we had the idea to write a Smalltalk interpreter in (a subset of) Smalltalk, together with a translator from that subset to C.
The current Squeak interpreter combines a classic ST-80 interpreter with a simple yet efficient 32-bit direct-pointer object memory, and incremental garbage collector. It also includes a BitBlt graphics system that supports 1-, 2-, 4-, and 8-bit indexed colors, as well as 16- and 32-bit rgb colors, plus a "warp drive" that supports fast rotations and other affine transformations, as well as simple anti-aliasing. Other notable, and equally portable, abilities of Squeak include 16-bit sound input and output, and support for sockets and internet access.
That design, and adhering, for better or worse, to the image model (the entire state of Squeak is manifest in an image file), yielded a system of extreme portability and sharability. Any image file will run on any interpreter even if it was saved on very different hardware, with a very different OS, or no OS! Squeak's portability and sharability, plus its malleability (since it is all in Smalltalk, a competent Smalltalker can change anything about it), has aroused much interest in the academic community, and what I will call the "independent" computer science community. By this phrase, I include people who are not so interested in one language or OS over another, but who have some passion (numerical analysis, graphics, distributed computing, music synthesis, O-O education, etc.) and want a system that can provide the most flexible and immediate command over experiments in their field of interest.
There are two strong, often opposed forces at work in the Squeak team. But, we have managed to keep it together long enough that it's probably adequate to articulate the two and you can guess at where equilibrium will take us. These were most recently articulated in Alan's allusion to Koestler's metaphor of progress in two orthogonal planes: a horizontal pink plane of incremental improvement, and a vertical blue plane of paradigm shift. The colors are Alan's.
Pink plane forces involve making an ever-better Smalltalk-80 system that can serve a wide range of research and academic needs, while leveraging off the large body of ST-80 documentation, existing code archives, and synergy with high-performance commercial 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 current progress forces are aimed at a higher performing 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.
Blue plane forces involve a very 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, each offers significant benefits.
A fair portion of the new graphics model, based on the Morphic interface from 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 far simpler and yet more general. With the next release you will see presentation graphics support such as drop shadows and gradient fills, desktop publishing abilities 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 must understand what we're after. Our number one commitment is to an exquisite personal computing environment. Imagine a system as immediate and tactile as a sketch pad, in which you can effortlessly mingle writing, drawing, painting, and all 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, I said "personal" computing environment. This has many ramifications. One aspect is that things must stay small and simple enough that they remain comprehensible and accessible to one 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, instead, 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 will run just fine on any of the bare chips from Acorn, Hitachi or Mitsubishi, that cost $10-$20 each, with nothing but a BIOS.
We are now 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 a long term desire to somehow refactor the kernel into a dozen or so classes, with a dozen or so messages each.
We are also painfully aware of the poor state of Squeak documentation. We do not feel that existing ST-80 texts are the answer to this. Instead, we want to upgrade our tools for documentation, just as all our other tools, so that the entire system can be "read" from within itself as an "active essay" with hypertext links and embedded executable examples to explore. See Literate Squeaking.
This, of course, is all apple pie and motherhood, so let me attempt an entirely practical answer to your question of where Squeak will go in the next six months. I 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 time.
We intend to put out a new release, likely named 1.3, sometime in December. We hope this will include most of the new interpreter work, so it will be well tested by wide usage, and so experiments with further performance improvements are easy to perform within that release. That release will also include improvements to Morphic as stated above, and several improvements to music support, and a first try at improved internal documentation.
In the same time, the Squeak team plans to work entirely in Morphic, so we will exercize our optimization skills on raising performance there to the same level we see in MVC browsers. With the next release, likely in March-April 1998, you should be able to delete MVC, in the same way you can now delete Morphic if you want to save space. I hope we are fairly far along with interpreter tuning by then, so overall system speed will be up by a factor of two or so over what we have now. I hope to see a few web-based tutorials you can click on in the startup image, and that take you through the whole of Squeak with lots of executable examples along the way. I see Squeak 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 personal favorite of mine is type inference. I would like to see Squeak be adequately reflective by then that if it looks at itself for a while, it can tell you the types of every variable in the system. You will likely see some experiments in other syntax and language features, but within this time, I see no compelling reason to drop the common language synergy we now have going.
I hope this gives you some sense of where we are going. Of course it may turn out to be untrue. I'll feel good if we can just keep doing fun stuff and sharing it with our fellow Squeakers. – Dan Ingalls
