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