Hacker News Reader

Comment by secstate | Hacker News Reader

I feel like if I were a pilot with even a modicum of engineering and language experience, I'd be pretty frustrated that they aren't using something like Haskell that provides a certain level of runtime security. C++ seems like it has enough ways to generate a memory leak to sink a boat, or drop a fighter out of the sky.

View on HN

C++ may not be the best choice, but a language like Haskell would be worse for an aviation application for a number of reasons:

1) Memory on the hardware is tightly constrained and controlled, and you need some visibility into its usage at any given time. Even if it exposes you to null pointer errors and the like.

2) Along the same lines, throughput must be predictable and is tightly constrained. Anything happening at runtime that can't be predicted at compile time is, for a safety critical aviation application, a huge risk and is usually explicitly forbidden by the requirements.

3) Haskell is relatively new. C++ has stood the test of time and the DoD can be sure plenty of C++ programmers will still be around in 30+ years.

All of these are dealbreakers from the DoD's perspective. The technical risks associated with handling your own memory and not having provably safe code can be addressed with enough time and expense. Since the DoD is not short on money and operates on time scales of years or decades, this is acceptable. In a startup or academic environment, the balance of risks and resources is completely different. But believe it or not, the DoD and commercial aviation entities actually do look at the tradeoffs associated with the tools they choose and don't simply choose them out of inertia.

Source: I develop commercial jet engine software, where many of the same resource/risk tradeoffs exist.

No disagreement, but wanted to point out that groups like Galois have been using Haskell-embedded, compile-to-C DSLs in some interesting ways recently:

http://smaccmpilot.org/images/dronecon-talk.pdf

This has the potential for nice compile-time guarantees without the runtime cost (and potentially at much lower cost than full formal verification)

(also, fwiw, Haskell has been around since 1990, making it about 7 years younger than C++)

While initially this seems like a good idea, and I thought things like this for a while... I'm sure they are using a real time operating system. Imagine having things garbage collect for you when trying to fire a missile. This may seem inconsequential, but reliability is everything.

https://en.wikipedia.org/wiki/Real-time_operating_system

edit: also, time/space leaks in haskell.

Haskell cannot give hard real-time guarantees, to my knowledge. C++ can (if you don't use some features like exception and dynamic_casts [1])

[1] I should point out that dynamic_cast is a little tricky -- http://www.stroustrup.com/fdc_jcse.pdf

You also can't call new or malloc (unless your heap is has deterministic worst-case timing).

In addition to the other replies, Haskell lacks a proper ISO or ANSI standard.

I think that current safety-critical best practices (what real software engineers actually do) do a good job at correcting the warts inherent to the C family while respecting the need for real-time execution. Not clear what Haskell brings to the table here (or on other embedded systems in general).

That's exactly what the DoD created Ada for. Unfortunately, programmers that know Ada seem to be in short supply.

Reply on news.ycombinator.com