In message , Tom
Anderson writes

Not C++, Java - good god, you don't imagine i'd use a language with
manual memory management and pointer arithmetic in a safety-critical
system, do you?


Well, yes, actually, because you know what you have and can test and fix
every piece of it, rather than relying on an over-complicated
third-party runtime which has almost certainly not had adequate testing
for a safety-critical environment. I'd rather be using C, or a
Forth-type language.

--
1089

On Thu, 2 Feb 2006, 1089 wrote:

In message , Tom Anderson
writes

Not C++, Java - good god, you don't imagine i'd use a language with
manual memory management and pointer arithmetic in a safety-critical
system, do you?

Well, yes, actually, because you know what you have and can test and fix
every piece of it, rather than relying on an over-complicated
third-party runtime which has almost certainly not had adequate testing
for a safety-critical environment.

Depends on the runtime. And on what you're doing, of course - as
Greenspun's tenth law observes, any large program includes a
reimplementation of much of the functionality of an over-complicated
runtime, so you'll generally be better off using a more sophisticated
language to start with. If you're doing something fairly simple that
doesn't need much dynamic memory, C might be better; this example is
probably in the latter class, to be honest.

I'd rather be using C, or a Forth-type language.

Or Ada - still (usually) no GC, but at least much better type-safety.

Highly entertaining article comparing Ada, C, C++ and Java to the original
Ada requirements document (used as a gold standard for a language for
serious embedded systems):

http://www.adahome.com/History/Steelman/steeltab.htm

Ada wins, Java and C++ are neck-and-neck, and C comes in last. Mostly,
though, that's because C doesn't specify thread-related stuff as part of
the language; i think C + POSIX would do a lot better.

tom

--
Better to die on your feet than live on your knees. -- Emiliano Zapata