| |
| |
| |
| |
================
A preliminary answer to the question of how the Squeak Team actually uses Squeak and what their expectations for Squeak's future are.
Well, a first cut at the context of our work can be gleaned from the "Where is Squeak Headed" section of the Squeak home page, at http://squeak.cs.uiuc.edu/headed.html. This was written, as one can tell, late last year, but much of the vision part is still relevant, and it's gratifying to see that much of the planned implementation has actually come to pass. That said, it is probably time for a bit of an update. I'll take a crack at this in a message in the next couple of days, and if it comes out right, maybe we can use it to update the home page.
It would not be correct to say that we are afraid of publicity. After all, we put a lot of effort into our presentation at OOPSLA last year, and we continue to participate actively in this mail distribution list and other web-based foci such as the above-mentioned home page and the several Squeak WIKIs. This, though (in case it's not obvious), is not an attempt at PR but rather a labor of love – we get much more back from sharing this work with all the other great Squeakers who follow and contribute to the dialogue here.
The simple fact is that we do not feel the time is yet right to "go public" in the usual sense of the phrase.
We believe that Squeak can be a first-class authoring environment for active media, along the lines of Hypercard done right. We believe that Squeak can be a system that one could approach as an arithmetic engine, a string-processing engine, a graphics engine, or a music engine, and be able to probe deeper and deeper in any area, emerging with a complete understanding of these areas, enlightened by an understading of how they are all the same, and empowered with the ability to mold the system into any new configuration that makes sense. We believe that Squeak can be as small as any rival system, making it a great base for interesting PDA software, and that it can be nearly as fast as any rival system, making it a reasonable choice for even the most serious software development work.
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 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.
To make Smalltalk a truly universal language with equal chances for anyone, we might want to let go of English. But then we need a language which is not too hard to learn. We might try... Esperanto! It has only 16 grammar rules and the rest is just learning words.
It would be something different if we would start programming Smalltalk a la Esperanto. We could even write these e-mails in Esperanto. – ReinierVanLoon
At the risk of starting a distracting thread, I will admit to thinking about this very idea at the predawn of Smalltalk. Esperanto was one of the candidates, but I didn't think that it's inflectional nature matched up well to the isolating (a special linguistic term for non-inflectional languages like Mandarin) characteristics of mathematical and programming languages.
In the sixties I was very enamored of Basic English (of Ogden and Richards) and thought it would make a terrific computer language, especially for rules, descriptions, and searching. Some of BE's influence is in Smalltalk: BE is a noun heavy language with "no" real verbs or verb inflections for tense. The equivalent of verbs are sythesized in BE from the nouns and by making various prepositional phrases, all of this without violating standard English conventions: Ogden was a philologist and very clever. BE is highly polymorphic in several ways, including metaphorically. About 25,000 major books have been translated into BE. Generally speaking, BE's style can be quite astonishingly clean and graceful. There is still a lot to be said for BE's approach.
Another language that I followed for quite some time was Loglan, of James Cook Brown at the U of Florida. Its structure was that of predicate calculus sugared via a grammar like Mandarin Chinese, a morphology derived from the main languages of the world, and a phonology organized to produce very pleasing sentences; that would also be very easy to recognize via computer.
One of the counter arguments to this approach is that one good thing about a language like Smalltalk, is that it doesn't lead one astray via false analogies to natural languages; like, say, hypertalk does. Along these lines, what we should do is to simply "humanize" how Smalltalk deals with world concepts. As a tiny example, it would help in many ways if Smalltalk had "units": meters, ergs, liters, etc. There are many other aspects of human languages that could be installed in a redisigned language, and that might be as easy a way to make it universal as to adapt an 80 year old pastiche. I think we know more about language than Ogden and Zamenhof did, partly thanks to them, and could likely come up with something better. – Alan Kay
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.