>They appear to use 3 different compilers for this reason (Ada)
I understand why Ada is used for safety-critical applications, but I have to wonder: Does the fact that Ada is a relatively old and unfriendly language lead to more bugs than it prevents? My mind would probably go blank if I had to stare at Ada code for 8 hours a day.
What if we used Haskell for all non-realtime safety-critical functionality in aircraft? With a few extra rules to prevent stack overflows, I think I'd trust a million-line Haskell program over a million-line Ada program (although it would probably be more like ten-thousand-line Haskell program vs million-line Ada program).
Ada is proven in this area and generates fast, efficient code that is suitable for embedded systems. Ada's last revision is 2012. What do you find unfriendly?
I would most certainly not trust Haskell over Ada in embedded system work.
As an aside, I've been playing with learning Ada for a while (and all of the books I have from the last time poked at it are very out of date). Do you happen to know of any good references, online (Better!) or off?
Yeah, I would avoid trusting something hard-realtime to a language with lazy evaluation and garbage collection, even if it's quite trustworthy for other purposes.
(IIRC, these programs don't even use malloc, let alone garbage collection :)
MISRA discourages use of malloc (because you can deviate with clear documentation as to why) but it's not at all unheard of. That said, many embedded systems don't come with a usable implementation of malloc so the safe default is to write your own memory manager (safer but not always possible: use a well tested one) that uses static memory pools to allocate dynamic memory.
Any time you're using malloc() you run the risk of running out of memory, which is a very very bad thing for a safety-critical embedded system. Statically allocated, fixed-size things are good, as are algorithms that are designed not to require O(n) space to perform their processing.
There are many safety-critical systems that aren't hard realtime. Radio transponders, human interface systems, life support systems.
In fact, I'd say a great way to do it would be to implement all the hard realtime bits in some low-level, pain-in-the-ass language like Ada and then wrap all that unpleasant stuff in a high-level language that is very unfriendly to implementation bugs (like Haskell).
>> Radio transponders, human interface systems, life support systems.
Don't think you know what a hard real time system is. Both radio transponders and life support systems have to be hard real time. Motors and antennas don't magically communicate with your userland "apps," they're controlled by precisely timed code. The "human interface systems" (could you have brought to the conversation a more generic term?) to all of these are often, too, hard real time because that's the easiest way to prove something is safe and test the edge cases. For all intents and purposes, anything "soft real time" has a kernel and kernels are monolithic disasters waiting to happen for anyone who needs timing guarantees (hint: if your life depends on it, it needs timing guarantees).
On top of that is the unfriendliness of Haskell to the real world of hiring (and this is Boeing for godzilla's sake) and it's lack of proper testing in such an environment, although I'm sure there are those who use it in embedded.
>Motors and antennas don't magically communicate with your userland "apps," they're controlled by precisely timed code.
Motors and antennas are usually managed by hardware or dedicated uCs, not PFC software. Aircraft aren't running their telemetry off GnuRadio, and aircraft PFCs sure as hell aren't worrying about servo timing.
"Human interface systems" I thought would be self explanatory; pilots don't care if their plane UIs take 5us or 5ms to update. They can't react on those time scales anyway. Hell, you could probably code all the user-facing avionics stuff in Javascript and be fine.
> pilots don't care if their plan UIs take 5us or 5ms to update
Hard real-time doesn't mean "fast", it means having guaranteed upper bounds on response time. In order to get those guarantees, uninteruptable code paths need to be short and critical parts of the systems need to be simple, which often also leads to fast response. However, the difference between soft and hard realtime systems is the guarantees.
A soft real-time system that has a 5ms mean update time but has a 1e-6 chance of taking 10 seconds is much less useful than a hard real-time system that has a 15ms mean update time with a hard upper-bound of 50ms.
Which is why Rust is so interesting. It has deterministic upper bounds on performance. Not many new languages have this feature. Should eventually be useful for real-time systems and game developers.
But based on my meager experience in the language, I disagree that Ada is a massive pain in the ass to program in. It's probably less verbose and friendlier than Java, for example. Certainly easier than programming in C, and much less prone to fatal mistakes.
Do you have any links about the upper bounds of performance in Rust? I have a passive interest in embedded and Rust and that sounds pretty interesting.
You know, there are other languages than Haskell doing interesting things. Ada2012 for example, introduced design by contract with support for formal verification in conforming subprograms. This may be a near term more practical path than dependent types. Highly interesting.
I am a big Haskell fan but no, just, no. That would be a terrible idea because of how inherently unpredictable lazy evaluation is. Replace "Haskell" with OCaml or SML though, and I definitely agree.
Also as others have commented there are usually special requirements for embedded systems that may even occasionally require one to drop down to assembly (e.g. to get the code in the right place to execute if you're on bare metal).
This sounds like a gross misunderstanding of the kinds of guarantees made by Haskell's static systems.
The closest you're going to get it something like Atom [0] which is used to program a few different hard realtime systems. If you look at the Atom docs, however, you'll quickly find that programming in Atom is nothing like programming in Haskell---it's merely embedded there. The type system helps to ensure that your embedding does falter, but most of the errors still live in the sublanguage and I'm not sure how far Haskell's type system goes toward reducing those.
Avionics software is written in an environment where, _if_ such a problem as a programming language being "old and unfriendly" introduced bugs, that would have been noticed and mitigated.
What's so great about Haskell? It has no particular safety features compared to other languages, I think.
It won't help with with static analysis of any numeric types (though you can turn bad conversions into type errors, it can't tell if an explicit conversion is right or not) and the timing of anything is really hard to reason out.
The things that matter in critical embedded systems are typically not captured by type systems: memory boundedness, running time upper bounds, overflows,... For these things even (controlled) C is a better option than Haskell today.
I understand why Ada is used for safety-critical applications, but I have to wonder: Does the fact that Ada is a relatively old and unfriendly language lead to more bugs than it prevents? My mind would probably go blank if I had to stare at Ada code for 8 hours a day.
What if we used Haskell for all non-realtime safety-critical functionality in aircraft? With a few extra rules to prevent stack overflows, I think I'd trust a million-line Haskell program over a million-line Ada program (although it would probably be more like ten-thousand-line Haskell program vs million-line Ada program).