Jonathan Cunningham (jlc@sofluc.demon.co.uk) wrote:
: Has anyone thought yet about implementing Java within Poplog?
No. I though about a pop11 engine using the JavaVM though! :-) Running Java
code on the poplog VM should be pretty painless since the Java VM is somewhat
less complicated than the pop one (less baggage - Sorry pop fans, it had to be
said :). Going in the other direction is currently very difficult because the
Java VM has no decent way of creating closures as the Lisp people have found
out. There was talk of persuading Sun to incorporate such a facility in
future versions, but I don't think anything has come of it yet. I'm not an
expert on either btw, I just read a lot of stuff.
: I've just started looking at the language. I have a strong hunch that
: it may turn out to become a very important general purpose language
: in about, say, two years time.
Good call. I think the current fuss is premature too. Current problems with it
are than Suns tools are flaky and slow. The sun runtime engine executes code
about 20 times slower than the equivalent C. There are other runtimes becoming
available. One is Kaffee which is free-er than Sun's (its GPL'd) and another
is Borlands. Both of these implement Just-In-Time compilation as the popVM
would, but the Borland one costs and the other one is flaky being freeware.
Another reason not to bother with Java for Real Work(tm) is the lack of other
tools - debuggers, application framework libraries. Again, these are becoming
available, but they are in their first versions now and are subject to
constant flux.
: Also, it has something I've suggested a couple of times as an option for
: pop11: limited types.
Me like this idea too. Errors that involve operations on incorrect types
failing are the hardest to catch by far in my (admittedly small) experience.
You could scatter your code with predicates to check the type of a variable,
but apart from being slow, they would make code very cloudy.
: I'm sure variables get used more than they get assigned to
Yup. The incremental garbage-collectors used in JavaVMs rely on this fact to
stay efficient. A value may be read with impunity, but writes are trapped and
invoke the marking phase of the gc.
: I haven't got far with my reading yet, but so far the Java core looks
: quite small: most of the power will come (as in poplog) from all the
: associated libraries that will be developed.
Thats a weakness in some peoples opinion. Sun expects to ship big libraries
with the runtime system that applets can make use of. This keeps down the size
of the applet because all these libraries are already on the target machine.
The problem is that until the standard libraries are very much more mature
than they are now (one guy got so fed up with their geometry manager they
ported 'packer' from Tcl/Tk to java) people will want to do things that the
standard libraries can't. This leads them to use a custom library with their
applet that has to be loaded every time the applet is. This makes loading way
slow and puts people off Java very quickly. Corollary: relying in library
support is OK, but you need to have damn good libraries as standard.
: Historically, big languages have always lost out (PL/1 and Algol-68 spring
: to mind). C++ may be the next to go: it has too much baggage (no
: language needs both references and pointers, as just one example).
: What will C++ be replaced by? There are several candidates, but it won't
: be Smalltalk, nor Lisp (nor Pop11 :-( ). It's unlikely to be Eiffel.
: I would be willing to place a small bet that it will be some language
: derived from, and very similar to, Java.
Talk of C++'s death is premature. References are neater than pointers, but
they don't cut ice when it comes to system programming. Java by its very
design requires a support system even when compiled to native code. In short
you couldn't write your operating-system in Java and more importantly you
couldn't write your JavaVM in Java. This lack of symmetry puts people off.
Also the things that were left out of Java to make it neater (other than
pointers) are very useful. They wouldn't have made it into C++ if they weren't
useful. Take multiple-inheritance for example. Someone described OO languages
that don't support MI as 'Death by sub-classing'.
: Everyone and their cat are implementing Java interpreters at the moment.
: It is a short step to compiling native code instead. The Poplog environment
: could be a good way to cash in on the rush, since most of the initial
: necessary Java class library functionality is already available in
: Poplog, and the Poplog VM is already a good match for Java semantics.
Yes, there are lots of VMs being developed as I mention above. It would be an
interesting exercise, but I don't see how poplog could "cash-in on the rush".
If I can download Kaffee for free, compile it with my free c++ compiler and
run it on my free OS, why would I want a poplog vm? And if you mention support
provided by a commercial operation, I have to re-iterate my point about _all_
Java technology being half-baked at the moment, commercial or otherwise.
>rant mode off<
Richard
--
===============================================================
"Between the hours of twelve and two, those nagging doubts will
come to you, be paranoid parents cos they're after your kids,
who don't know what an aryan master-race is..."
----------------------Carter USM - The Only Loony In Town------
Richard Matthias, or richardm@cogs.susx.ac.uk to you! :-)
===============================================================
|