2008/2/4, Paul D. Fernhout <pdfernhout at kurtz-fernhout.com>:
> As I said in my post: "Yes I know there have been a few Java/JVM Smalltalks
> (including at least two or three derived from Squeak). But maybe one with a
> clearer license might help to push beyond that continuing contentious
> issue." I also brought up up other technology issues related to complexity
> and rebuilding from scratch.
>
> 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)? How well factored is it?
> Does it have nay hope to be supported by a community? Does it take advantage
> of the Java/JVM platform, including threading and multi-processor support?
> Or interoperate easily back and forth with Java libraries like Jython can?

IMHO the reference for Java interoperability is Groovy. A language
similar to Ruby but made with one goal in mind: make it work on the
JVM. At the end of the day it is pure Java, everything has Java
semantics. Doing this compromise they ended up with a language much
more useful than JRuby. Because for example Strings do not only have
Java semantics, they are Java Strings. Instead of wrappers a MOP is
used to access objects. Is makes interoperability much easier. You can
compile Java classes against Groovy classes without problems.

This is what makes Grails kill in the enterprise market. Take the
ideas from Rails to the JVM, integrate really well, leverage the
underlying platform (Spring, Hibernate) and you end up with people
like Oracle supporting you.

Cheers
Philippe

> 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 (the reason I included that
> dispatching code example in Java, which is a different approach than the
> usual Squeak VM) I think there might be overall benefits from using Java/JVM
> objects but with a Squeak-like dispatching system for Squeak defined code
> that was not compiled down to native code (like via translation to
> Scala/JVM). Still, using Java/JVM objects is just one possible aspect of
> such a system, and not essential to the value of such a thing (it makes
> "become:" and proxying harder, while it makes other things much easier).
>
> To me, that example just shows again everything wrong with the Squeak
> development process and why it is so frustrating to deal with it -- an
> undocumented decompiled hack stands in for "free"-ly-licensed modular robust
> software -- and eclipses the possibility of something better. :-)
> Squeak's great success is its own worst enemy in that respect. :-)
>
> Other comments by me on Smalltalk on the JVM here:
>   http://www.mail-archive.com/help-smalltalk@gnu.org/msg00796.html
>   http://www.mail-archive.com/help-smalltalk@gnu.org/msg00803.html
> (although now I am leaning to Scala as an intermediate language above the
> JVM instead of Kawa).
>
> --Paul Fernhout
>
> Klaus D. Witzel wrote:
> > It *is* running on that VM, even has source code,
> > http://lists.squeakfoundation.org/pipermail/squeak-dev/2007-July/118649.html
>
>