> > > mSt is a subset of Smalltalk that maps directly onto C
> > > constructs. It excludes blocks, message sending and even objects.
> >
> > This I'm not sure I agree with. I don't know how mSt can in any way be
> > a subset of SmallTalk if it doesn't support the three main elements that
> > make SmallTalk what it is. I think our equivalent of mSt should be Ruby
> > itself or a real subset of it.
> >
> I agree with you. I've looked into Squeak and its VM a bit more and it
> actually seems it is written in C with a Smalltalk syntax (IMHO, it can
> still be a subset though!), ie. its so far from Smalltalk the only
> benefit you get compared to writing it in C is you can develop and run it
> in your Smalltalk environment (might be important though).

I'm not an expert on the Squeak VM, but I have been a Squeak user for a
while...

It's definitely non-trivial for the VM development to use the Smalltalk
environment.  As Dan Ingalls writes, none of the Squeak team wanted to work
in C and they wanted to use Smalltalk debugging tools.  If Dan Ingalls and
Alan Kay are willing to consider mSt (actually, I think they call it Slang)
a subset of Smalltalk, who am I to argue?

The biggest advantage that the Squeak team has gotten from their VM strategy
is portability -- porting Squeak to new OS's is very simple, since most of
the work is already being done for you in Smalltalk -- the VM is much
smaller, relative to the code library then it is in, say, Java.  For
example, at OOPSLA a few years ago, they did a demo of Squeak running on a
Motorola chip with no operating system installed.

As far as performance, without getting drawn in to the difficulties of
benchmarking between languages, it's pretty good.  The main thing that helps
is that Squeak (and Smalltalks in general) define native-language primitives
for critical methods in the system to boost performance, but if the
native-language primitive isn't there for some reason, the Smalltalk version
is run.  Again, I'm not the person to ask about the details, but there will
be a book coming out next month with some descriptions of their porting
procedure.

Noel Rappin

-------------
Noel Rappin
Openwave
Principal Software Engineer, Internal Development
Noel.Rappin / openwave.com
-------------

This message does not necessarily reflect the opinions of Openwave Systems