*Development Direction*

[Brian Rice]

Ahem! Apparently I can only post to Google Groups through their web  
interface? How disappointing. The message went through after a third  
try, unfortunately not allowing a CC.

On Sep 27, 2006, at 7:20 PM, Brian Rice wrote:

> (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

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : /archives/slate/attachments/20060927/85631520/PGP.pgp