prototypes vs classes was: Re: Sun's HotSpot
DanI at wdi.disney.com
Thu Oct 15 19:59:52 UTC 1998
I wrote a message for this thread last week, but decided to sit on it because I didn't want to add more fuel to the fire. Things seem to have died down, though, so I've decided to sent it after all...
Alan Kay wrote:
>The big idea is "messaging" -- that is what the kernal of Smalltalk/Squeak
>is all about...
Thanks for pointing this out. My take on this is a bit different, but you have succeeded in putting it into a nutshell. Here's my slightly different slant on it...
I view Squeak as a sort of "Little Engine that Could". At its core it has a very simple and efficient object memory, and a fairly simple and efficient bytecode engine. This is the messaging kernel. On top of this, we have a fairly standard Smalltalk-80 system with some nice network, sound, and graphics extensions, and some other works in progress.
The Smalltalk-80 language is a great base-camp for our forays into more exciting territory. Much of the Squeak synergy in industry, academia, and on this mail list derives from the fact that Squeak remains at its core a mainstream programming environment that runs on many platforms. However it would be a mistake to confuse the mission with the base-camp.
It takes less than a page of Squeak to establish a reasonable protocol-based dialect in Squeak (starting with prototypes, cloning, inst-specific behavior and no metclasses). Nothing is preventing anyone from doing this. And it would make a much more concrete discussion (as David Stes points out) to examine the actual results achieved.
Other attributes often associated with protoype languages are alluded to in this thread, such as an implementation of instance variables that allows proper overriding of inherited state. This, too, is relatively simple to achieve as a dialect in the current image, without any need to abandon the base camp. The Compiler can already compile variable accesses as messages: look at references to temps when you execute a do-it in the debugger's code pane. Here again, if we wrote a page of Squeak, we would have an interesting artifact to play with, and we wouldn't have to write a lot of prose to argue its virtues.
I'm not saying stop talking. I'm saying start building.
More information about the Squeak-dev