On Mon, 1 Nov 1999, Alain Farmer <[EMAIL PROTECTED]> wrote:
> Alain : I suppose that the ideal programming language
> would then be Java, so as to make it multi-platform ..
>
> Michael Fair : The Java language itself isn't what
> makes it cross-platform. It's the Java Bytecodes that
> the JVM then interprets which gives it's
> cross-platform-ness.
Correct. And C and C++ are actually at least as good for cross
platform development as Java, but only for the things that these
languages have built in support for. Unfortunately this doesn't
include any sort of GUI API, which means a lot of work is required to
build a cross platform graphics framework. Not that this hasn't
discouraged dozens of organizations from developing such an API (see
the platform independent GUI FAQ
(http://www.zeta.org.au/~rosko/pigui.htm) for the whole story).
> Alain: Yes, I know that it is not the Java language
> but rather the Virtual Machine concept and the
> underlying bytecodes that makes Java multi-platform.
> Java is .. um arguably the best implementation of the
> VM approach though (so far).
>
> Michael Fair : Metacard also has a MetaTalk->Java Byte
> Code compiler which they have not bothered to clean up
> and release because the JVM's can't give the required
> performance yet (We should listen to Scott about this
> before we think about using Java for cross platform
> reasons).
>
> Alain: That would indeed be interesting. Scott?
This overstates the amount of work we've done on this (we've only done
the design and enough functions to get a rough estimate of the size of
the Java bytecode version), but the basic math is unescapable: there
is a large amount machine code in a full-blown xTalk interpreter and
if you replace all of this with byte code and then interpret that (or
even JIT compile it), you're looking at an order of magnitude or more
drop in performance. Another data point is that the few commercial
apps out there developed in Java aren't exactly burning up the charts
and I haven't seen a single review of a Java application that didn't
ding it for poor performance. Add another level of interpretation in
there and you've got an unusable product.
I wouldn't completely rule out using Java for this project, but it
would probably only be for the ability to add components. It might
also be possible to use Java for the UI stuff, but IMHO, the
interpreter core would have to be written in C++ to have reasonable
performance. Unfortunately calling Java from C++ is no picnic, and so
trying to mix the two in this way may not be practical. It'd be worth
a try, though.
As for using XML as a file format, I'd like to see this tried too, but
I suspect it's not practical for performance reasons and because it's
not possible to do dynamic file updating (like HyperCard and SuperCard
do) using the stream-oriented XML format. The "SIF" format Uli
mentioned was defined only for the SuperCard to MetaCard converter and
is not a good system for general export/import of stack data for other
purposes. If we were starting that project now, we'd probably use XML
instead. It'd be harder to write and slower than SIF, but at least
we'd have the technology available to use for other things (like
marketing: you want XML? We got XML! Even if you don't know what
you're going to be using it for... ;-)
Regards,
Scott
********************************************************
Scott Raney [EMAIL PROTECTED] http://www.metacard.com
MetaCard: You know, there's an easier way to do that...
