Re: Java's poor performance? Not really - pick the right tool for the job!

At 11:21 AM 4/27/2004 +0200, Johan Helsingius wrote:
>At 20:32 26/04/2004 -0600, Bruce Boyes wrote:
>
> > It's only "the same as C" if you compare it to a C interpreter which runs
> > on dozens of hardware platforms, and includes a broad array of tested and
> > robust, standards-based libraries. There is no such C beast. Remember - 
> C has *no I/O* in its spec!!
>
>Ummh... I don't want to start a language war, but just in the name of acuracy,
>the C standard IO library *is* part of the spec.

I'm not starting a language war either, but the "standard I/O library" for 
C is something like this:
http://ou800doc.caldera.com/SDK_sysprog/_Standard_IO_Library.html
It's file I/O, not the I/O I was meaning, and does not include _any_ serial 
or parallel I/O, TCP/IP, etc. That was my point. All the most common 
external device I/O is *completely* absent from C. And every C vendor takes 
a little different approach to adding their own. I've written code in more 
different serial I/O C libraries than I care to remember, and most of them 
I paid big $$$ for. Back in the day a C serial library cost $250-$500 - 
remember Greenleaf and LifeBoat? TurboPower Async Pro? Etc.

This is a big win for Java: How secure is "Joe's TCP/IP Stack for C"? I'd 
bet my application on Java's security model any day over Microsoft or 
Rabbit or ______.

This is also a big win for OpenSource - a lot of critical eyes looking at 
an open standard tends to produce a much more robust product than some 
proprietary by an handful of people behind closed doors.

And really the benefit of Java is reliability and programmer efficiency. 
There, it's far more efficient than C, as most users who've done both will 
attest.

Here's an interesting paper written several years ago on Java compared to C++:
http://www.shadowlink.net/~raycox/Java.html

Maybe others have some better/newer links

>Yes, you won't find a C *interpreter* that runs on "dozens of hardware
>platforms", but you will find very good *compilers* (such as gcc) that
>run on hundreds if not thousands of systems.

Agreed, but these systems can't even standardize on how big an "int" is or 
which end of the int is the big one. Ah yes, those fondly wasted hours 
grappling with Borland vs Microsoft compiler-isms...

>The reason to use java instead of C is not portability (and I think TINI 
>is a good
>example of how java implementations differ) but the fact that it's all too 
>easy
>to lose your hands and feet with the sharp edges of C (runaway pointers and
>memory leaks).

Ha ha! That's a great way to describe it. "Sharp edges".

A great cartoon from years ago shows two programmers starting at a smoking 
PC with a jagged arrow jutting out the side. One programmer is saying "I've 
never seen a runaway pointer do that before!"

Java isn't the answer for everything. We still use assy code and C here, 
where it makes the best fit. Sometimes Delphi (basically Java in a 
different wrapper), Python, etc are better.

Bruce


>         Julf

------- WWW.SYSTRONIX.COM ----------
   Real embedded Java and much more
www.jrealtime.com and www.tstik.com
+1-801-534-1017  Salt Lake City, USA  


_______________________________________________
TINI mailing list
TINI-6tN4nzCoH/[email protected]
To UNSUBSCRIBE, edit your profile, or see list archives:
http://lists.dalsemi.com/mailman/listinfo/tini