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

Ignacio Vivona altobarba at gmail.com
Tue Feb 5 12:00:17 UTC 2008


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

On Feb 5, 2008 5:43 AM, Michael Haupt <mhaupt at gmail.com> wrote:

> Hi Paul,
>
> On Feb 4, 2008 11:44 PM, Paul D. Fernhout <pdfernhout at kurtz-fernhout.com>
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20080205/cba51dfa/attachment.htm


More information about the Squeak-dev mailing list