Philippe-

Thanks for the great links, as well as your previous comments on different
JVM languages.

More JVM languages are here:
  "Programming Languages for the Java Virtual Machine"
  http://www.robert-tolksdorf.de/vmlanguages.html
The Smalltalk-like ones listed are: SmallWorld, SmalltalkJVM, Talks2, and
Bistro. None of them are in active development near as I can see, though
Alexandre has a SmallWorld, variant he linked to. Maybe Talks2 is a going
thing, but it's hard to tell from the web site. I think their demo came
before Dan's:
  http://www.architur.de/deutsch/produkte/talks2/t2_demo.html

In planning going forward, it seems Java is going to support dynamic
languages (like by hiring the JRuby folks). Squeak and other Smalltalks can
either be part of that process or not. As near as I can tell, they are not?

It seems to me that a Smalltalk that runs well on, say, Java 1.5, and
interoperates in some way with the JVM and Java objects (ideally, as
smoothly as Jython does, for a much more dynamic language than Groovy) is a
beginning. After that, one could expect that as the years go by dynamic
language support on the JVM would only get better with new Java versions.

A big issue is how to keep the virtues and values of Squeak and Smalltalk at
the same time it might run on the JVM and interoperate smoothly. Of course,
that entails deciding what those are? Maybe we can't even have them all, but
then we have to prioritize them and see if we need them all, and then decide
if it is worth doing. Like wondering if "become:" is still that important if
you have other ways of changing class lookup (as Alexandre brings up). But
even if compromises are made, for me, the real issue is more am I using
Jython (or whatever other JVM language) or am I using Smalltalk with
Squeak's ideals on the JVM.

By the way, Clojure is a dynamic (lisp-derived) language for the JVM
intended to support dynamic (and functional) programming, and to do so in an
incremental way. Of all the languages I've read about for the JVM, it seems
most Squeak-like in some ways.
  http://clojure.sourceforge.net/
  http://lambda-the-ultimate.org/node/2547
"Clojure is a dynamic programming language that targets the Java Virtual
Machine. It is designed to be a general-purpose language, combining the
approachability and interactive development of a scripting language with an
efficient and robust infrastructure for multithreaded programming. Clojure
is a compiled language - it compiles directly to JVM bytecode, yet remains
completely dynamic. Every feature supported by Clojure is supported at
runtime. Clojure provides easy access to the Java frameworks, with optional
type hints and type inference, to ensure that calls to Java can avoid
reflection. Clojure is a dialect of Lisp, and shares with Lisp the
code-as-data philosophy and a powerful macro system. Clojure is
predominantly a functional programming language, and features a rich set of
immutable, persistent data structures. When mutable state is needed, Clojure
offers a software transactional memory system and reactive Agent system that
ensure clean, correct, multithreaded designs. I hope you find Clojure's
combination of facilities elegant, powerful, practical and fun to use."

I tend to lean towards a Smalltalk on top of Scala/JVM, because I'd rather
write a Smalltalk translator to a type-inferencing functional language with
better exception handling than for Java (less code to output, perhaps easier
to support higher level Smalltalk concepts).

But if I was just going to slap Smalltalk syntax on top of an existing JVM
language, Clojure might be a better choice. At the very least, Clojure is a
great proof of concept that Squeak-on-the-JVM with full interoperability
with Java objects is possible. It goes beyond Jython in support for
Squeak-like dynamic development. See:
  http://clojure.sourceforge.net/features/dynamic.html
"First and foremost, Clojure is dynamic. That means that a Clojure program
is not just something you compile and run, but something with which you can
interact. Clojure is not a language abstraction, but an environment, where
almost all of the language constructs are reified, and thus can be examined
and changed. This leads to a substantially different experience from running
a program, examining its results (or failures) and trying again. In
particular, you can grow your program, with data loaded, adding features,
fixing bugs, testing, in an unbroken stream."

Sounds a lot like the Squeak ideal to me. Yes, some things it misses -- the
self-containedness of Squeak, which both good and bad. Maybe it is simply
that the future of Smalltalk should not be to be self-contained but to be
interoperable, and the benefits will outweigh the losses?

Personally, I was a Java and JVM hater for a long time. I fought against it
for years in favor of Smalltalk (mainly VisualWorks then, but even Squeak)
or later in favor of CPython. I still think Java is an awful language; I
tend to use the terser Jython instead. But, a decade or more later, the JVM
is not that bad. Computers are 1000X more powerful so Swing performs
adequately on most desktops. They have got most of the bugs out of the core
libraries. Multi-threading usually works acceptability if you follow the
guidelines. I still held out because of the "Java Trap" since Sun's Java
wasn't free, but now it (almost) is. The JVM has problems, but so does
everything. :-)

I feel some updated version of the Squeak ideals (like focusing more on
collaborative development than personal development) and related Squeak
applications (even eToys and Croquet) could do quite well running on the JVM
because of the leverage it gives to influence the rest of the world. I used
to think Python could be that vehicle  (before Java was free) but now I see
Python (as Jython) as being just one peer on the JVM, interoperability with
a Squeak/JVM (or whatever it's called).

Still, I can accept that Squeak will loose some of its value as a
top-to-bottom stack., But it's not like the Squeak code or Squeak VMs in C
will vanish. We will just have more choices. There might be some loss of
developers to a Squeak/JVM, but given the potential upside of millions of
Java developers trying Squeak/JVM, I would think ultimately the benefit
would flow both ways as people who like Squeak/JVM start investigating its
origins. Having said that, I am still think gin maybe GNU/Smalltalk would be
a better choice for drawing from for much of the core to avoid licensing
issues. And then Squeak applications (like Croquet or eToys, even the Squeak
debugger, etc.) with whatever licensing could then run on top of that core.

--Paul Fernhout

Philippe Marschall wrote:
> Hi
> 
> Assuming interoperability with Java is your top concern (and not with
> existing Smalltalk code):
> Wait for Java 1.7:
> http://blogs.sun.com/jrose/entry/notes_on_an_architecture_for
> Use a MOP instead of wrappers/proxies:
> http://dynalang.sourceforge.net/
> 
> Compromise, use Java where you can. E.g. use ArrayList and HashMap
> instead of OrderedCollection and Dictionary.