*Development Direction*

[Brian Rice]

(Reposted from my google account.)

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