Strongtalk VM for Squeak

Daniel Vainsencher danielv at techunix.technion.ac.il
Tue Sep 19 20:12:22 UTC 2006


BTW, I got curious, here's some good stuff:

1. A rough description of the Strongtalk type system: 
http://www.bracha.org/nwst.html
2. A summary of Gilad Bracha's 2004 position on optional type systems. 
Very clear. The most interesting statement (the only one I'm not sure I 
agree with) is roughly: the semantics of the program should not depend 
on the type system, and the type system should not depend on the type 
inference system. IOW - one should be free to adopt even lower 
declaration levels than Hindley-Milner inference requires, if an 
appropriate inference engine exists. It is at:
http://pico.vub.ac.be/~wdmeuter/RDL04/papers/Bracha.pdf#search=%22strongtalk%20type%20%22

Daniel

Ramon Leon wrote:
>> True, but you're ignoring some information that we do have. 
>> People who "get" Smalltalk have considered the type system 
>> worth their while to make, even though they knew (and this 
>> was novel at the time) that it was not there for performance 
>> reasons. So some set of Smalltalkers have considered this an 
>> improvement to Smalltalk. I would treat this as a hint that 
>> Strongtalk types are not like Java (et al) types, and 
>> therefore require separate evaluation based on facts.
>>     
>
> An experiment that hasn't proven itself in the wild yet.  As for why add
> types, Dave Griswold says "One of the biggest among these in my mind was the
> lack of any kind of type system, which although it makes the language
> extremely flexible, also means that organizing and understanding large-scale
> software systems is a lot harder."  Maybe this is true, but I don't think
> so, I haven't found manifest types helpful in this arena, maybe others do.
> In fact, I'd think unit tests are far more helpful in types, for building
> large systems.  Manifest types force one to write lot's of duplicate code
> that differs only in the type declarations, of course, them being optional
> does change that.
>
>   
>> You do know the types are optional, right? considering that 
>> they are, do you know exactly how they affect programming in 
>> it, that you can say they'd ruin the language?
>>     
>
> Yes, I know they're optional, but if they aren't use for optimization, and
> the dynamically typed code is just as fast... What's the point?  They make
> the code ugly, and less maintainable imho.  I don't want to think like the
> computer, I want the computer to think like me.
>
>   
>> In the context of the previous discussion, by every "major" 
>> language, I presume you mean every popular language. This is 
>>     
>
> Yes, I meant popular languages.
>
>   
>> generally true, but not strictly so. Another direction in 
>> which they are being pulled is the ML kind of typing - 
>> mandatory, strong, static, but not (very) verbose. 
>> Verbosity is replaced by type inference. We all know that 
>> static verbose types are bad because they cost too much in 
>> malleability for what they give in reasoning over programs.
>>     
>
> Type inference is cool, I was only dissing manifest types.
>
>   
>> Are you sure that *optional*, static, non-verbose types would 
>> still not be worth it? (btw, I'm not claiming the Strongtalk 
>> type system is such - I have no idea whether it is verbose).
>>     
>
> No, I was only saying manifest types aren't worth it, type inference rocks.
>
>   
>>>> Another point about typing:  would the typing information 
>>>>         
>> be useful 
>>     
>>>> for improving the developer tools (e.g. refactoring could be more 
>>>> precise)?
>>>>         
>
> Yes, but type inferencing can do this without making the code ugly and
> forcing the programmer to help the compiler.
>
>   
>> Do you (or anyone else listening) know the Strongtalk typing 
>> system well enough to attest to this or refute it?
>>     
>
> I don't claim too, but I've look at samples, and don't like it.
>
>   
>> I for one hope that the different open advanced VM efforts 
>> (Coke, Exupery, Strongtalk) can cross fertilize.
>>     
>>> but Squeak, needs to remain Squeak,
>>>       
>> That was never Squeak's purpose. Squeak needs to replace 
>> Squeak with something better. That will never happen if our 
>> assumption is that Squeak (or Smalltalk) is any kind of 
>> global optimum.
>>     
>
> One of Squeak's coolest things, is that it's open in a way that a C++ VM
> wouldn't be, it allows experimentation with the language, look at Croquet,
> Tweak, Seaside (added continuation), things that "probably" couldn't have
> been done so easily if squeak had a C++ VM.  Seaside still hasn't been
> ported to all the other dialects of Smalltalk because their VM's don't allow
> continuations to be easily added, something that was only a few lines of
> code in Squeak.  I'd certainly like to see Squeak take things from this VM,
> but not just adopt it as a better VM, because it isn't.  It might be faster,
> but faster isn't better.
>
>   
>>> StrongTalk is the wrong direction.
>>>       
>> Stated, yes. Demonstrated, no.
>>
>> Daniel
>>     
>
> Only my opinion, obviously.
>
>
>   




More information about the Squeak-dev mailing list