OSNews

First of all, I'd like to point out that the article's writing style is atrocious. I'm especially offended by the use of non-words like "open-sourcability". Its good to use parallel constructs in your titles, but you don't get to cheat in the process! Moreover, even if "sourcability" was a word, it wouldn't mean what the author obviously intends it to mean. Rather, it would mean that it is easier to put C code under an open source license than other code.

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

As a result of the fact that many Lisp-like languages compile to C, this is equally true for them.

gcc is a full-featured and robust compiler for ANSI C, and it's open-source.

And CMUCL is a full-featured and robust compile for ANSI CL, and it's open-source. The point being?

You cannot effectively duplicate a struct containing other structs in Java or in Perl as you can in C.

But you can in Lisp! Or Dylan. Or Scheme. Or Ocaml. Or a dozen other languages!

You cannot work with interrupts, DMAs, and other hardware elements.

C has no conception of interrupts, DMAs, etc. Indeed, you *cannot* generally write an interrupt handler entirely in C without extra-lingual mechanisms. On x86, this is due to the need to use IRET to end an interrupt. Implementations of any language could include such functionality.

You can compile a C library and distribute it as is.

Only if you link it statically. On the other hand, you can do the same for a statically-linked Lisp/Dylan/Scheme/ML app too! The machine doesn't care what language the binary originally was!

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.

The need to create bindings is:

a) Trivial, thanks to auto-generators.
b) An artifact of the fact that the system is implemented in C!

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.

This argument is completely true, and the only decent one in the bunch. System libraries, on *NIX, should be written in C. C is so primitive that its easy to bind any language to it, and accessibility should be the primary goal of a system library.

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.

This is argument is only partially valid. Real-time control apps can (and have been) written in high-level languages using a real-time GC. I do, however, find it entertaining how many people think that C gets you most of the way to being real-time. Most code written in C is *unsuitable* for real-time use. Most C code uses memory management techniques (eg: reference counting --- it's everywhere, even in the Linux kernel), that are unsuitable for real-time systems. Most C malloc() implementations aren't suitable for real-time systems either. Writing real-time code is hard, and given a good real-time GC, isn't particularly harder in a high-level language than in C.

As for simulations, they can be written just fine in high-level languages. The nice thing about most simulations is that they are generally quite parallizable. You don't really care if the code is only half as fast, because buying twice as many machines to run it is cheap. Indeed, if using a high-level language allows you to spend more time making the code parallelizable, even if the code is half as fast, it's a net performance win!

Graphics and 3D code may or may not be unsuitable for high-level languages. Graphics code tends to have tight inner loops that are relatively easy for a VM or compiler to optimize. The JVM is particularly good at optimizing numeric algorithms written in a very low-level style (so is CMUCL, actually). For 3D code, the CPU performance question becomes almost a non-issue. Most 3D processing these days happens on a GPU, so as long as the main program is fast enough to bottleneck the GPU, it's "fast enough".