Re: [Help-smalltalk] GST on the JVM?

[Paul D. Fernhout]

David-

My thanks to you, Paolo and Brad for all your thoughts on this.

I guess one issue here is always that the current audience of a mailing 
list and project is self-selecting; if you are not comfortable with a 
Smalltalk tied strongly to C, then you are probably not using GST. Nothing 
wrong with that. I think it's a good question of who a GST/JVM would be of 
interest to. For me, I like the Swing libraries; I like the possibility of 
using Java3D; I like the idea of being able to interface with compiled 
Java code without C pointer issues; I like the idea of being able to just 
have one jar file anyone can download and use on almost any computer (in 
theory); I like the idea of a one-click web start application; I like the 
idea of a good threading model that runs on multi-processors like the new 
four core Mac Pro. I've actually been fairly happy using Jython with Swing 
-- except for missing the keyword syntax and great integrated tools and 
other advantages Smalltalk offers. So there are several things that might 
appeal to me which may be of less interest to people already using GST 
as-it-is. Of course, if they appeal to me, they might appeal to others who 
are not here yet. Still, are they worth the trouble of making another 
variant on an existing Smalltalk or building yet another one -- or even of 
just living with a more clumsy syntax of, say, Jython? That's a question I 
wrestle with for myself.

On Lua, I had looked at that and Parrot (and others) a few months ago, but 
the bottom line for me, if I did anything towards another Smalltalk 
variant, is to have the least work to do :-)  and get the most support 
from related communities with their libraries and existing code. I don't 
care a lot about performance so I'm willing to take a 4-10X or whatever 
hit using the JVM with a mismatch for dynamic language features if I 
suddenly have few portability worries and access to some good libraries I 
already know. Still I wonder how bad that performance hit will really be 
these days since I continually see people saying Java is now as fast or 
father than C++ for many things (better compilers and the HotSpot JVM).
  http://www.javaworld.com/javaworld/jw-02-1998/jw-02-jperf_p.html
Of course, perhaps the comparisons are always with C++ as C is just faster 
for VM type things? :-) Also, if I can leverage Java libraries for things 
like 3D then it may not matter if the Smalltalk language itself is a 
little slow. Python gets pretty far having good libraries for things like 
numerical arrays while otherwise being a tiny fraction of C++ speed for 
loops and such.

What would matter to me from the maintainer side -- as a tradeoff against 
speed -- would simply be making my life as easy as possible to spend as 
much time on tools and applications and the least time on low-level 
porting issues, while still being reasonably crossplatform (even with 
Swing's usual warts). I fought against Java at the start, and not just 
because VisualWorks consulting back then paid the rent. :-) I'd say VW of 
ten years ago is still better than the JVM of today. Certainly the first 
five years of Java was a disaster for most people -- projects after 
project abandoned and all sorts of problems with missing features, random 
bugs only on one platform, abysmal performance, and so on. Not to mention 
how mismatched static languages are as a general choice for most 
dynamically changing business and R&D applications (great for implementing 
a VM though). And then there was RMS on "the Java trap". Nonetheless, it's 
now ten years after Java got going, and things have changed bit by bit. 
Many Smalltalk ideas have migrated into Java (Swing, HotSpot), and it has 
so many libraries, and it is (supposedly) going to be GPL at the core. And 
computers are about 100X to 1000X faster than in 1996, so performance 
issues really don't matter as much for the kind of things I want to do 
(mainly educational simulations and knowledge sharing apps). So, I feel 
Java is perhaps finally at the point where it is stable enough that I can 
expect "write once, debug once, run everywhere" to finally be close to 
being true (instead of "write once, debug everywhere"). And I think even 
the best C++ programmer has to admit by now that Java (with garbage 
collection) is easier to program in and maintain than C or C++ (at least, 
for most people and most applications, special cases excepted). Obviously 
there will always be problems with incompatibilities of different Java 
versions and missing libraries and so on.  But with Sun's Java now going 
GPL, I might expect it will become even more ubiquitous and better 
supported by those who want it for other reasons.

I don't mind Bistro's changes to the language because I think they form a 
superset more or less of Smalltalk (though I do not fully understand them 
yet). But Bistro does not have an active user community, sadly. Still, it 
might make possible sense for the kernel and compiler. I've also played 
with the Jython codebase so I know it is possible to integrate with Java 
in various ways and Jython does this superbly without any need for 
explicitly declaring types or such.

Lately I've also been looking at what various Scheme implementations on 
the JVM can do (such as Kawa), contemplating I could perhaps use one of 
those as a quick-and-dirty bridge from, say, GST to the JVM, with GST 
supplying the Smalltalk libraries for an image.

Imagine if GST methods in a browser could be written in either Smalltalk 
or Kawa Scheme (kind of like Smalltalk/X lets you write code in C I 
think). Eventually I could write a Smalltalk->Scheme translator (if one 
does not exist already) to dispense with writing any Scheme directly for 
primitives (which could then be in Smalltalk).

So for example:
http://cvs.savannah.gnu.org/viewcvs/smalltalk/kernel/File.st?rev=1.3&root=smalltalk&view=markup

Object subclass: #File
...
  stringError: errno
    <cCall: 'strerror' returning: #string args: #(#int)>!

could become:

  stringError: errno
    <kawaCall: 'strerror' returning: #string args: #(#int)>!

or even:

    stringError: errno
      <kawa: (gst-return 'string (strerror (gst-local-int errno))>!

Of course this might not be worth the trouble compare to just making a 
java equivalent of <cCall>. And any extensive use of Scheme would then 
have to be debugged, which gets into even more complexity.

Anyway, lots of possibilities, just exploring them right now.

One thing that would be helpful to me is pondering -- if I used GST as a 
base and threw away anything that was a rough fit, and ignoring complete 
Java library integration, how long do people think it might take a good 
programmer in person-months to get a new kernel in another language under 
GST's existing Smalltalk libraries (whether Java, Scheme, OCaml, or 
otherwise) given the existing kernel as a guide? A week? A month? a year?

I also remember seeing Paolo had worked on a Java runtime for GST:
  http://cvs.savannah.gnu.org/viewcvs/smalltalk/java/?root=smalltalk
so maybe some of those ideas might somehow help with direct callbacks from 
Java to Smalltalk (if I wanted to avoid a Scheme middle layer to dispatch 
those)? Seems easy enough to call another language -- getting a call back 
is quite a bit trickier.

Thanks again for the feedback. Probably all too daunting, but I thought 
I'd at least explore the possibility.

--Paul Fernhout

David Given wrote:
> Paul D. Fernhout wrote:
> [...]
>
> > but I was wondering, now that Sun has officially announced moving the
> > JVM and Java SE to the GPL, if there would be any serious interest
> > (especially at the GNU/FSF level) in having GNU Smalltalk on the JVM?
>
>
> I've been vaguely thinking of that sort of thing. On the plus side, it would
> mean that it would be possible to use somebody else's fast, optimised VM for
> Smalltalk, which has vast performance and portability benefits... but on the
> minus side, Java's a lousy match. Smalltalk is far more dynamic than Java is,
> and the VM is accordingly different. Trying to add methods to a class, for
> example, is (AFAIK) impossible in Java. This means you'd have to either
> reimplement the class system without using the JVM's native one, or do
> horrible workarounds.
>
> (Talks2, for example, explicitly invokes the command-line Java compiler every
> time it needs to compile Smalltalk code. St/JVM doesn't have any technical
> information, but reading between the lines it looks like they have a
> standalone compiler which doesn't allow dynamic updates once it's been
> compiled. Bistro redefined the language to make life easier for themselves.)
>
> A better match could be something like the Lua VM, which is tiny, portable,
> and extremely fast, but that doesn't get you the benefits of using the JVM.
>
> [...]
>
> > In any case, it seemed like, respecting the license, that GNU Smalltalk
> > could be a source of much good code for such a system and its image. I
> > know right now GST is heavily tied to C etc., so no doubt there would be
> > a bunch of work, perhaps best done along the lines of what Squeak does
> > to generate the VM from translating Smalltalk-like code.
>
>
> It'd require a total redesign from the ground up. Sorry. You may be able to
> use the pure-Smalltalk part of the standard library, but I doubt very much if
> any of the runtime would be at all useful.