OSNews

From the article:

"ANSI C is portable for every architecture there's a gcc backend or any other compiler for."

ANSI C shouldn't have to rely on GCC for portability, that's kind of the point of it being ANSI C in the first place. Later, he laments about the aspects that he cannot use when trying to run cross platform compiling against Visual C++ etc.

"With Java you rely on Sun's whims."

With Java, you have to rely on Suns Java Compatability Kit and testing. There are several JVMs that appear to meet this standard, otherwise they could not be called "Java". Not just Sun, but IBM, BEA, HP, Apple, as well as several Java implementations on embedded devices. I acknowledge that there are other platform and higher level issues with portability at the embedded layer that are not part of the the Java language and JVM itself per se.

"Open-source high level languages are better (especially if they can be compiled using gcc or supply a gcc back-end), but nonetheless, C is still more portable than anything written using it."

Since these are simply C programs, their portability is manifest to the ability of the coders to create portable code. They are no more or no less portable than other C programs that leverage similar facilities exposed by the operating system.

"gcc is a full-featured and robust compiler for ANSI C, and it's open-source. Sun's Java distribution has a very problematic license. It's not distributed as part of most Linux distributions due to this."

License has nothing to do with portability. I imagine, but do not know, that Auto Lisp in AutoCAD is quite portable, for a contrived example.

"You cannot effectively duplicate a struct containing other structs in Java or in Perl as you can in C. This is due to the fact that in these languages every struct is a reference. You cannot work with interrupts, DMAs, and other hardware elements. It's much harder to write your own custom fine-grained memory-management routines."

Hmm, a quick google seems to conflict with those claims, as there seems to be at least some folks doing real time embedded Java.

"Many problem domains call for ANSI C."

True, but those domains are getting fewer and fewer.

"You can compile a C library and distribute it as is. With Java or Perl one often needs a substantial run-time."

I can compile a Java library and distribute that alone to anyone who has the Java runtime. There are a gazillion of the libraries available on the internet. Arguably, I'd say there are more (at least in terms of variety and number) of these than for C, particularly higher level frameworks and development runtimes (I don't know if there is an equivalent C Library to something like, say, Spring for example). In fact, it can be argued that simply the simplicity of distributing and incorporating 3rd party libraries is what has lead to the rapid rise and use of Java in the first place.

Finally, that Java library binary is portable to the PC, Mac, Solaris, AIX, HPUX, Linux, FreeBSD, AS/400, PowerPC, i386, ARM, etc. Whereas a C library binary typically is not.

"There's no fork() in Java, and not many other UNIX system calls. You need to create bindings for them (which require JNI) or work around them. Perl and other languages, usually don't have this limitation.

To some extent, this is also true when working on Microsoft Windows, where some of the system calls and APIs are not available in the Java distribution by Sun."

That's ok, C has to jump through a lot of hoops to leverage the JVM, so, what's your point? UNIX programs have to jump through there own circles of Hell to run on Windows, and it's even worse running Windows programs on UNIX. What's this have to do with C as a language?

"A C library can be used by Perl code, Python code, Tcl code, Ruby code, to a lesser extent Java code, etc. Code written in a high-level language is mostly usable only in that language."

Ah HA! The crux of the issue. I see here you don't consider C a high level language.

"And naturally there's speed and memory consumption. Often when speed or low memory consumption is the issue, one cannot use a high-level language, because it may have a lot of overhead in both areas or both. Many real-time applications (i.e: applications that should respond to events within a given time) must be written in a low-level language for that reason."

Umm...no, Real Time Applications must not necessarily be written in a low level language. Real Time has to do with guaranteed dispatch and response, much of which is dependant on the runtime. It all depends on the environment, how fast your processor is, and how much you're doing in your real time event handlers. Lots of applications that need real time response can be handled with all sorts of runtimes. There are and have been real time systems written in Lisp, for example, and folks are doing that in Java today.

"Other applications like that are applications that simply can never be fast enough: various APIs, virtual machines, simulations, graphics, audio, video and 3-D programs, etc."

And of the billions of lines of code written each year by developers around the world, less and less and less of it is in that low level space, most of it is in integrating those low level aspects into high level applications. Even modern video games are more and more runtime engines driven and integrated by scripting languages.

Back in the day, we'd write assembly interrupt handlers to be leveraged by C code. Once we could do that, assembly dropped from mainstream to a very nichey area of development. C is suffering the same fate. Now we're writing C handlers for Java/Python/Ruby code, and most of the folks writing in those languages are not looking back. The domain they develop in rarely need the pain of writing C code to perform the task they need.

Certainly there are exceptions, and certainly C has its place in the world, but that place is getting smaller and smaller every day.