I suppose it's time for me to chime in.

On Sep 27, 2006, at 6:51 PM, Josh Scholar wrote:

> I've been interested in implementing a dynamic language with full type
> feedback optimization...
>
> I looked at squeak and decided that the VM code is unredeemable.  It's
> a complete mess, badly designed, not at all object oriented at its
> base, unprofessional, disorganized and developed by too many people
> over the years.  It's so bad that I think it's almost impossible to
> do simple things like adding a new field to a type that used by
> primitives. They didn't use such modern advances as structures in
> the C
> code.
>
> The original idea of Squeak, to write Smalltalk in Smalltalk was a
> hack
> that only lasted long enough to debug the first version of the VM.
> After that, the emulation code rotted, no longer works, and cannot be
> resurrected.  There are semantic differences between the Smalltalk
> emulation and the C compiled code that cannot be bridged.
>
> So while it should be possible to port classes over from Squeak, I
> wouldn't dare try to switch the VM over.  Certainly not with a
> populated image...

The "clean" Slate project (at http://slate.tunes.org ) set out to
implement a system with these problems fixed, and references the
Strongtalk system with good reason. We did make a better C-
translation dialect that we refer to as Pidgin - it is much more
idiomatic and does generate C structure types and uses them. The
source code is extremely clean and concise - the VM is separated
modularly into a bytecode interpreter, object memory, garbage
collector, and supporting primitive operations. Each module has an
understandable interface and can be replaced easily. Interpreters can
be used as processes and could potentially be usable for OS-level
thread managers.

However, we never had the kind of attention paid to the VM which
would complete the dynamic inlining. But more importantly, the
libraries were *designed* with an inlining compiler in mind (and we
used the Strongtalk collection libraries as a template), so there is
a tremendous method-call overhead with even simple operations, making
Slate much slower than Squeak right now, even if its libraries are
much more powerful and well-factored. Hence, I would also like to
participate in this discussion and hopefully partner with someone to
bring these advances to Slate. Without them, the project is just not
very useful.

> The images are another problem.  When I stopped following a year
> ago or
> so, there was no way to create a clean image, and my attempts to run
> each of the many image walkers failed. I love the process and data
> persistence of Smalltalk images, but the Squeak project shows just how
> pernicious it is to have a system with no ability to start clean.

There is a Squeak image bootstrap package now, and Spoon also has a
solution for this. Granted, they are difficult to work with. Slate
does bootstrap images from scratch (even via make-rule), albeit not
in an incredibly flexible way. That said, we can make everything from
a "3+4" image up to a full one with development support by changing
the code-sources specification list.

> Just try to find out what each object and process in a Squeak image
> does... and good luck with that! However I do think that someone had
> written a special VM to help solve that problem - one which weeded out
> objects that weren't used in a specific run, or which ported objects
> from a different image as needed, with user interaction for each
> object.

Craig Latta's Squeak-based Spoon project includes tools for doing
that thing, for example using bit-flags to trace whether methods were
called.

> My own project hasn't gotten far enough to make public yet, but I
> decided on Ruby as much better starting point because the code is
> readable and pretty clean - an amazing accomplishment for a project
> written in C.

Unfortunately, Ruby's grammar is problematic, as conversations I've
had with some MetaRuby contributors has indicated.

--
-Brian
http://tunes.org/~water/brice.vcf