ian (i.r.) woollard wrote:
> I've just started playing with Java actually.
So did I - it's nice to see a system that makes
Smalltalk seem fast :-)
> I notice that when you want to execute Java you have to translate the
> Java code into byte codes so that they can be executed. However,
> there's nothing very special about the bytecodes that Java produces;
> in theory they could be written in any language.
The Java bytecodes could be generated from other languages,
but they are rather closely coupled to the semantics of
> So I was thinking: Self could do with the portability that byte codes
Self already has bytecodes, though they are less
optimized of interpretation than Java's or Smalltalk's.
They are much simpler and nicer, on the other hand.
> What's to stop someone producing a Self -> java bytecode
You would have to create a lot of "helper classes"
that would have to be fetched with every Self applet.
The speed would be terrible compared even to a
naive Self interpreter.
Of course, you could use Ole Agesen's static type
analysis and extractor to feed an optimized Java
bytecode generator, but that is hardly trivial.
> The advantages are:
> - great portability
> - great availability
These are very tempting advantages.
> - okish speed (will get much better as the byte code interpreters
Interpreters won't ever get good enough, and just in time
compilation simply doesn't compare to the adaptive
compilation Self already has.
> - making the typeless style of programming more popular
Not really - Java bytecode are typed, so you have to
give up that advantage of Self in order to deliver
the applets. You still retain the comfort of typelessness
while developing, of course.
> The problems I see are:
> - interfacing to libraries (presumably not too hard)
No - Self already gets along with Unix and X11 libs
> - actually writing the compiler (presumably Jecels version of self is
> closest to what you want)
I don't think so. A lot of people have asked me about
Java bytecodes so I have given this some thought (not
as much as the people at Sun, of course!). The best
hope would be to use a conventional Self system for
development and then a special extractor and compiler
to get the Java bytecodes.
> - the dynamic nature of self code (e.g. potentially changing
> constants/code on the fly-don't know whether Java allows this sort of
> self modifying code!)
Non of this could be used in the final applets, but
that wouldn't be a problem in practice. Self applications
can potentially create new kinds of objects on the
fly, but how many do it besides the development
Steve Dekorte wrote:
> Sounds like you'll need a Self VM in Java.
> Then you don't need to worry about a Self->Java byte code compiler.
> Of course it would be slow.
That is another alternative, but you would need extraction
to send the applets to the users anyway. So in the end,
it doesn't matter what your development Self is based
Sandor Lengyel x2495 wrote:
> I am also interested in java, but it is a very slow language. Its advantage
> 1. There will be Just in time Compilers. Which change the byte code into
> machine code. They are not platform independent.
Well, I would like to see how these compilers handle
dynamic lookups before I give my opinion of them.
> 2. Hardware which will be optimized for the byte code.
I'll believe it when I see it. I think that a Java VM
in hardware won't outperform the just-in-time compilers
on other platforms but will be used to save memory
Mitochondrion wrote [among other things]:
> I suspect the Ada project (a reference to which I could probably find if
> someone wanted) worked well because of a tight mapping between Java
> classes and Ada classes.
Exactly. Java bytecodes have a superset of the functionality
needed for Pascal or Ada, but only a subset of that needed
for Self or Lisp.
> Java is more than a language; it's also a national obsession, a lot of
> excitement, and a lot of hype. No reason not to take advantage of the
> energy! In a sense, Java is also about an increase in interest in OO
> programming and in good design.
You are right, which is why I feel so bad about the
conclusion I have reached about this whole issue. I think
that the best alternative is to port a simple Self
interpreter to the same platforms Java runs on, doing
it as a "plug-in" for Netscape and Explorer as well. If
done correclty, this would offer enough additional
functionality to justify the effort.
This has the whole Java hype machine against it, of
course, but it might raise some sympathy in the Smalltalk