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.
_______________________________________________
help-smalltalk mailing list
help-smalltalk@gnu.org
http://lists.gnu.org/mailman/listinfo/help-smalltalk