On Mon, 19 Mar 2007, Mitchell Wisidagamage wrote:
I'm a c fan myself. However when I was doing the "safety-critical
systems" module I was deeply disappointed to learn that c isn't "safe"
and sometimes "not recommended" (by IEC 1508 when developing safety
critical systems).
Languages tend to get less "safe" as they expect the programmer to deal
with more characteristics of the machine that a program runs on.
Programmers are likely to make mistakes while writing their programs, so
one of the tasks of a programming language is to protect the programmer
against expressing programs could behave badly (e.g. crash). The
type-system that a compiler implements in its type-checking phase, should
catch as many errors as possible. Ideally, a type-checker should guarantee
that a program will never crash during run-time, but this problem is
undecidable for any reasonable programming language.
I can understand why c is considered naughty but isn't it bad
programming (systems development) to blame rather than the flexibility
of the language?
The "flexibility" of the language is making it easier for a programmer to
mess up. If safety is a concern (e.g. you're writing software that will
control a nuclear power-plant), then I would prefer safety over
flexibility. On the other hand, if you're interested in getting as much
performance as possible out of the hardware that you've got, a "flexible"
(i.e. "unsafe") language is probably what you want.
I'm wondering what languages are actually used when developing critical
systems (such as aviation and missile control systems?).
I have no idea what is being used in practice, but I do know that the Ada
programming language was developed for the US DoD specifically for
building critical systems.
On a separate note, if you're interested in relatively "safe" languages
that allow you to do parallel programming and if you are willing to
sacrifice a little bit of performance, have a look at functional
programming languages such as Haskell (www.haskell.org). Functional
languages have pleasant properties (e.g. referential transparency) w/r/t
parallellization of code. The GHC compiler is producing pretty efficient
code nowadays and supports Software Transactional Memory. STM will let you
elegantly write parallel programs for a shared memory machine while
preventing the programmer from having to use locking to prevent race
conditions. Without locks, you will also not encounter typical concurrency
problems such as deadlock, livelock, or starvation. With the "many-core
revolution" looming, I think STM is something to keep an eye on.
Best regards,
Martijn de Vries
_______________________________________________
Beowulf mailing list, Beowulf@beowulf.org
To change your subscription (digest mode or unsubscribe) visit
http://www.beowulf.org/mailman/listinfo/beowulf
