Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon.

Pages: 1-

MISSION CRITICAL SOFTWARE

Name: Anonymous 2014-03-12 5:02

Besides sounding like a sales term taken directly from scripture of The Laughing Monkey Clan[1],
I am asking you guys: what language (do you|should I) use to develop mission-critical software? (Stuff like autopilots or reactor control systems.)

JPL has their own coding standard which "primarily target[s] the development of mission critical flight software written in the C programming language"[2], which makes for an interesting read.

I was thinking about Haskal, but since it's garbage collected and pausing for more than 150 ms would mean certain death for my project? It seems like a bad choice.

[1] http://thecodelesscode.com/names/Laughing+Monkey+Clan
[2] http://lars-lab.jpl.nasa.gov/JPL_Coding_Standard_C.pdf

Name: Anonymous 2014-03-12 7:32

My off-the-cuff response would be this: ``If you are writing mission-critical software, you better be reviewing/testing/verifying/fuzzing/etc. the code to hell and back, so your choice of language shouldn't matter beyond what you are productive with.''

The JPL coding standard you mention is a great example of that. I'd trust more in JPL-adhering C than I would in bog-standard Haskell any day. Going simply by your performance requirements, I'd pick the most efficient language possible (probably C), then put effort into making the result trustworthy, and having readily-available standards and static analyzers would be a big step in that direction. From that perspective, the difference between X and Y is whether the strictness necessary is built into the language, whether it's a third-party tool, or whether you have to write it yourself.

That said, I'm not sure Haskell would be so terrible as it seems. For example, a project in one of my hobby fields, seL4 by NICTA, is a microkernel that was formally verified because it was written in a subset of Haskell, then translated to [a subset of] C. That subset of Haskell was a restriction comparable to JPL's restrictions on C, and I vaguely remember reading that they have no (or trivial) GC in the result. (See http://ssrg.nicta.com.au/projects/seL4/ for a boatload of papers)

Name: Anonymous 2014-03-12 13:33

Ada

Name: Anonymous 2014-04-08 21:27

what about python?

Name: Anonymous 2014-04-09 5:04

>>4
What /about/ python?

Name: Anonymous 2014-04-09 10:44

>>5
Forced indentation of code?

In my reactor maintenance system?
I have no idea how likely that actually is.

Name: Anonymous 2014-04-09 13:18

>>4

It might be okay if you managed to catch all your exceptions properly.

Name: Anonymous 2014-04-09 14:48

>>2-4
If the code is for a ``mission critical'' real-time system pretty much anything that uses exceptions or GC is out. If you further restrict yourself to languages that more people actually know, that means C or a subset of C++.

>>2
I believe sel4 was prototyped in Haskell for model checking purposes, but the final implementation is in C.

Name: Anonymous 2014-04-09 14:53

Ada is cool

Name: Anonymous 2014-04-09 16:11

>>8
Well, in that case, screw this language crap. Get a PLC and use ladder logic.

Name: Anonymous 2014-04-10 5:39

>>10
Get back to me when you can run ladder logic with subroutines on a general purpose micro that costs $0.50.

Name: Anonymous 2014-04-10 12:30

>>11
No, because I don't want your 50 cent nuclear plant to exist.

Name: Anonymous 2014-04-10 13:46

>>12
Right, I forget this is the MISSION CRITICAL SOFTWARE thread.

Anyway, not every realtime system is a nuclear plant. Even if you are writing code for a nuclear plant, subroutines are a nice language feature to have. Nontrivial ladder programs take up a lot of page / screen space.

Don't change these.
Name: Email:
Entire Thread Thread List