swarm-support
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Portability


From: glen e. p. ropella
Subject: Re: Portability
Date: Fri, 21 Feb 1997 17:04:26 -0700

"manor" == "Manor Askenazi" <address@hidden> writes:

>> and the chips resident in automobiles, device drivers, medical
>> equipment...
manor> Prime targets for multi-agent simulation platforms, indeed!

Ahh, but the issue is not really whether these are Swarm targets
or not.  The issue is portability.  The point I'm trying to 
make by mentioning autos, device drivers, etc... is that if 
the language you're using is being used in manymany domains,
then the space of possible uses for the language is explored
more completely.  Period.  If that space is explored more completely,
then possible problems with the language will come to light sooner
and more fixes (not just one fix, but many) will be generated.
This means that the portability of the language will be well
understood.

So telling me that "Swarm will never be used in those systems"
is totally ineffectual.  The fact is that C is a better understood
language than Java.  And it will probably remain so for another
10 years.  And if the language, itself, is better understood, then
the portability of that language is better understood.

manor> Well, the speed argument is reasonable. Having said that my
manor> Indy already has a (MIPS) JIT compiler for java (and so does my
manor> 586 laptop, and so does your Sparc...). Besides, with built-in
manor> support for threading --- Java may actually make more sense
manor> with respect to fast implementation than C does.  Maybe not
manor> today, maybe not tomorrow, but soon, and for the ... well you
manor> get the idea.

My point has nothing to do with the existence of JITs.  I 
realize that there are JITs out there for a *few* targets (let's
say 10 just to give you a good large number, even though you
only listed 3).  But, compare that to the number of targets
for GCC (~30? minus many variants) and the objective-C part 
of that (assuming it's some large proper subset of GCC's).

Then next step is to ask "how hard is it to acquire a compiler
of language X that targets device Y?"  I don't have any estimate
of how hard it is to write a JIT for a C40 (or for anything else
for that matter), but, I do have an estimate for how hard it is
to write a GCC backend for a C40.  Given that the difficulty of
the former task is *undefined* (or, at least, ill-defined) and
the latter is defined (or, at least, more well-defined), I think
the answer is clear which language is more portable.

PS> Sure, you can write threaded code in C, C++ and sometimes even in
manor>     Objective-C, but how often does this really happen? Could
manor> it be that simplicity and language support actually matter?

I'd venture that threaded code is written more often in C than in
Java.  I can say this only because it's my guess that the frequency
and magnitude of projects done in C far outstrips that of Java.  This
will change.  And it will change pretty soon.  But, I don't think it
has changed, yet.

PPS> Could it be that I am turning into a language bigot? :-)

Well, there's a difference between language preference and language
bigotry.  No one should interpret anything I say as implying that Java
is not a good language to use for any project (including and
especially Swarm).  Every criticism I have of Java is mappable back to
the maturity of the language.  That's all.  This is not an argument
about which language is a better language.  This is an argument about
which language is more portable (i.e. capable of being used on many
platforms and for many applications).

Objective-C rides the coattails of C.  That's the only reason it's
even in the running.  C++ far outstrips Objective-C in the portability
regime.  And C far outstrips both of those, although that's changing
as well.  I might even go so far as to say that Ada might even be more
portable than Java.  But, so few people use it that I doubt it is.

The essence of what I'm trying to get across is that portability 
goes beyond data type formats.

glen



reply via email to

[Prev in Thread] Current Thread [Next in Thread]