Complexity and starting over on the JVM (was Re: Traits or not...)

Klaus D. Witzel klaus.witzel at cobss.com
Tue Feb 5 12:53:54 UTC 2008


On Tue, 05 Feb 2008 13:00:17 +0100, Ignacio Vivona wrote:

> Talking about running squeak on others VM, what about the CLR and the new
> DLR?

- http://www.google.com/search?q=Vista+Smalltalk+clr+dlr

> On Feb 5, 2008 5:43 AM, Michael Haupt wrote:
>
>> Hi Paul,
>>
>> On Feb 4, 2008 11:44 PM, Paul D. Fernhout wrote:
>> > As impressive as it was for Dan Ingalls to make that version of  
>> Squeak,
>> and
>> > then Pavel to decompile the result into source, so what? What is the
>> license
>> > of it all (either origins or decompiled version)?
>>
>> unclear. It's not officially released, there is no licensing statement.
>>
>> (Isn't it a true nuisance that, instead of caring about software and
>> complaining about and fixing bugs, we end up having to care about
>> legal stuff and complaining about and fixing licensing issues these
>> days?)
>>
>> > How well factored is it?
>>
>> It's very nice code, and nicely modularised into just 8 classes and 1
>> interface: the Squeak interface defines constants. The Main and
>> Starter classes are wrappers to get everything running. Then there are
>> SqueakVM and SqueakPrimitiveHandler for execution, Screen and BitBlt
>> for displaying, and SqueakImage and SqueakObject for representing
>> living things.
>>
>> > Does it have nay hope to be supported by a community?
>>
>> See above. Since it's not officially released, it's a problem. I'd be
>> in that community, for sure.
>>
>> > Does it take advantage of the Java/JVM platform, including threading  
>> and
>> multi-processor support?
>>
>> No; apart from garbage collection, it does not take advantage of the
>> JVM platform.
>>
>> > Or interoperate easily back and forth with Java libraries like Jython
>> can?
>>
>> That is not supported, but should be possible through primitives.
>> Object conversion may be challenging, though.
>>
>> > Also, that version is (to my understanding) defining its own objects,
>> not
>> > using Java/JVM's objects, so there is a performances hit as well as
>> other
>> > layers of complexity and interoperability issues
>>
>> You are right there. Then again, the difference for objects is larger
>> for Java and Squeak than for Java and Groovy - the latter's objects
>> are deliberately Java objects, and the entire object model of Groovy
>> has been designed with the Java object model in mind. SqueakOnJava is
>> "just" a Squeak implementation on top of the JVM, with an approach as
>> simple as possible.
>>
>> > To me, that example just shows again everything wrong with the Squeak
>> > development process and why it is so frustrating to deal with it
>>
>> I really would not put it that way. I don't believe SqueakOnJava was
>> intended to be the next big thing in Squeak progress; I rather believe
>> it was a case study, or a feasibility study. In other words,
>> SqueakOnJava, as I see it, is simply not part of the "Squeak
>> development process" (whatever that may be).
>>
>> Best,
>>
>> Michael
>>
>>





More information about the Squeak-dev mailing list