Hacker News Reader

Comment by ctz | Hacker News Reader

The obsession with C/C++ here is really weird. Like, take the MCO failure. That's a classic, textbook problem that can be structurally guaranteed not to happen with use of even a basic type system. It should be literally impossible to confuse values of different types/units/dimensions like this in something described as "safety-critical".

It seems like all the resources here are concerned with trying to whittle C/C++ into an appropriate choice of tool, rather than choosing a different tool. It seems like a 1980s-1990s mindset.

View on HN

As I understood the MCO failure, a better type system wouldn't have helped, as the issue was that another program expected metric input while the first program outputted US units.

Units can help verify that a formula within a program is correct (velocity v = 0.5(metric_acceleration)9.8 t;cout<<v.to_metric();) won't compile, for example.

But it won't help with Program 1:

velocity_imperial v = 0.5(metric_acceleration)9.8 t* t;cout<<v;

Program2:

velocity_metric v; cin>>v; BurnFor(doSomeRocketScienceToCalculateEngineBurn(v))

Don't pass numbers between programs without units.

Don't use non SI units.

People use non-SI units.

That doesn't solve everything. There are still textbooks published that use CGS instead of MKS units. Both of those are metric. Non-SI units are widely used in space (e.g., arcseconds).

The issue wasn't units. It was a break in (programming) "contract". Catching such bugs could introduce further (logic related string parsing) bugs.

A much more robust method (especially considering that this table was prepared in advance) would have been to have someone else to independently duplicate the work and compare results.

C/C++ is almost the only choice on most embedded systems, which is where most safety critical code lives.

> embedded systems, which is where most safety critical code lives

For how much longer?

The machines running self-driving cars aren't tiny little processors running single threaded code. They're basically full server racks worth of compute with multi-core cpus, gpus, and who knows what else.

The current approach of "use crufty-but-trustworthy hardware and never do anything too complex" doesn't scale to the next generation of "embedded".

Self driving machine code is inherently unsafe, as we don't have observability for the neural networks that run the most advanced models. The safety critical portion of the code focuses around running the base functions of the car.

One of the major hurdles to real Level 5 systems is proving their correctness.

> The safety critical portion of the code focuses around running the base functions of the car.

There's the rub. They don't meet the standards of safety-critical code, but they are safety critical.

I'm not sure how this challenge will be addressed, but I doubt the answer is "write everything in C". That approach works when your code is relatively simple, but doesn't scale when the code is actually extremely complex.

But the deep networks and such that power a self-driving car aren't written in C anyway. Or are they?

They most likely are written in C/C++ because the training algorithms are computationally intensive.

C++ skills are strongly desired by self driving car companies

https://hackernoon.com/five-skills-self-driving-companies-ne...

They are but that doesn't make them analyzable... Dealing with C craziness AND dnn craziness is silly. And the latter craziness is essential.

A team of PhDs using modern control theory can prove stability of an aerospace control loop across all different operating conditions.

A team of software engineers can then implement that with static analyzers and run time checkers during development to give confidence to an implementation.

Can you prove stability of a deep learning system across all possible operating conditions it may encounter?

Can you do the perception tasks that self driving platforms do using only control theory?

I'm not talking about self driving at all. I took your earlier comment to mean that the you thought the future of avionics control and other classical embedded problems would be using DNNs. Maybe that's not what you meant.

No. That would be crazy. Well maybe not really as planes become more autonomous and airspace more crowded, delivery drones and so on, but we are still a long way from that.

I was thinking more of self driving though.

That doesn't make any sense - Pascal and Ada and whatnot that were around in the 1980s, which means the fundamental problem can't be performance on any modern embedded chip. Besides which, you don't trade away stability for performance on a safety-critical chip!

It's not a technical challenge, but a political/business one. C/C++ won out.

> you don't trade away stability for performance on a safety-critical chip!

In a sane world, no. But we don't live in a sane world. We live in one where (on one system I worked on) it turned out a plane having an overheat (not fire) on one engine would cause the overheat on the other to fail to report to the pilots (corrected or I'd name and shame). And that wasn't just an issue of language, but of sound (or unsound in this case) logic. No one sits down and develops these things correctly. 10k lines of code (at most) on that project and most of it was just cobbled together in an ad hoc fashion.

Interestingly there was a comment about an Oberon Embedded IDE today: https://news.ycombinator.com/item?id=13806367

There are options available, namely Basic, Pascal, Ada, Java, Oberon compilers all the way down to microcontrolers (PIC and Cortex classes).

The main problem is that C and C++ won the political war and many devs don't even bother to look elsewhere.

Actually even C++, in spite of its safety improvements over C, has issues to cater to embedded devs.

Thankfully the IoT of shame is already making people aware that another path has to be taken.

How would a basic type system protect against incorrectly interpreting an imperial floating point value as a metric floating point value? That seems like an especially weak example, and fundamentally falls under the realm of logical fault endemic of every possible programming language.

There are legitimate gripes about C/C++, especially in a space with hostile actors an unknown inputs, but that example was particularly weak.

> How would a type system protect against unit confusion?

That this is a mistake that is possible to make in any language, but nevertheless this is also a problem that could be caught by a sufficiently good type system, if it was put to sufficiently good use. In fact, part of the justification for allowing user defined literals in C++ was precisely to make it easy and convenient to avoid mistakes like the Mars Climate Orbiter. Bjarne Stroustrup himself used that as an example in at least one talk he gave about C++11.

Andrew Kennedy's PhD thesis was about extending Hindley-Milner type inference to support units of measure. It basically boils down to extending unification to support equations over free abelian groups, which had been solved earlier in an abstract context. The approach could be integrated into just about any HM-derived language, and is shipping as part of F#.

Thanks! I was aware of the feature but not of its author.

https://blogs.msdn.microsoft.com/andrewkennedy/

https://channel9.msdn.com/Blogs/Charles/Andrew-Kennedy-F-Uni...

> How would a basic type system protect against incorrectly interpreting an imperial floating point value as a metric floating point value

"Better" / richer / more refined (aiming/aspiring at least!) type systems than C/++/Java/C#/Go/etc aim to make it ever-more "powerfully convenient, effortless, and free-of-cost to denote eg. such different units as uniquely distinct (yet 'compatible' when explicit conversion is finally expressly (and visibly (and searchably)) called for) types" that all source code cannot possibly mismatch accidentally without the compiler catching it --- however the issue remains that we don't, and possibly can't have type systems that also enforce such styles (rather than just relying on a developer's/team's own discipline & resolve to adhere to such convention even in the face of deadlines & budget/schedule pressures) unless we actually totally forbid primitives like lone (semantics ambiguous) ints, lone (likewise) floats etc. Similar to "bool blindness", there's the general issue of "primitive/scalar-type blindness" always lingering. Probably some PhD candidate will write a Haskell extension for such a scenario some day soon.

Though of course the next thing the deadline-driven developer will do is construct a single "semantic" int type used for all different semantic sorts kinds and types of "ints"......

For what is worth, C++ type system (which is more powerful than most, actually) make it simple to encode units (including composite units, exponents and ratios) and computing the exact units of complex expressions. See Boost.Units or std::chrono design. And with zero cost abstraction and little syntactic overhead of course.

The problem is getting embedded devs to use it, or when they do use it, not to write "C with C++ compiler" code.

of course, but it would be even harder to get them to use any other language other than C or C++.

A simple example would be instead of this:

    int temperature_a;
    int temperature_b;

or even:

    Temperature a;
    Temperature b;

you would have:

    Celsius a;
    Fahrenheit b;

And an assignment between a and b would be an error, as Celcius and Fahrenheit are different types. Going along this path then, if you can extend the type system enough:

    Yards width;
    Yards length;
    Acre  size = width * length; /* this would be okay */

    Yards width;
    Yards length;
    Yards height;
    Acre  money_bin = width * length * height; /* error */
    /* as acre is a measure of area, not volume */

Think of the type of calculations that the Unix command 'units' does, but built into a language instead of an application.

The Frink[1] language has units like this built in. Its pretty cool what you can do with it. I definitely agree that doing that or, at least, something like your code samples, is a good bug-avoidance idea.

[1] https://frinklang.org/

> How would a basic type system protect against incorrectly interpreting an imperial floating point value as a metric floating point value?

You could wrap your value in a typed data structure:

    enum LengthUnit {
      Feet(f64),
      Meters(f64),
    }

And provide conversion functions between them, then only operate on one type, `LengthUnit::Meters` and throw errors if `LengthUnit::Feet` is passed in.

I'm using Rust syntax here because it's fresher on my mind, but you could do the same with Haskell, OCaml, F#, etc. IIRC, OCaml would optimize away the outer structure so you wouldn't have much/if any performance hit. Presumably compilers for the other languages could/would do the same.

EDIT: for formatting and clarity.

Anecdotally I personally have talked to several people in the last few years who do things like write guidance systems for rockets. My limited sample frequently either worked in C or (a limited subset of) C++. Albeit with a variety of tooling on top to automatically test and catch a variety of kinds of common flaws.

So as weird as this may seem to you, that mindset is applicable much more recently than you might expect.

Most of them do use C due to talent and tooling available. They often subset it. They're also very careful. A small niche of the industry use Ada or embedded Java. A recent trend is toward model-driven develooment with tools such as Simulink, Stateflow, and Esterel SCADE.

This completely fits with the discussions that I had on the topic. However I have no idea how representative my random contacts were.

I have seen so many comments and references like this one, so I went and read the whole investigation report.

1. There was a spacecraft (MCO) and a module that was sending some data from the Earth.

2. The module was delivered late when MCO was on its way for 4 (!) months already before that staff manually calculated the needed data.

3. Some teams switched into "defensive mode" not willing to communicate and fixing the problem when it was clear.

MCO?

Mars Climate Orbiter http://sunnyday.mit.edu/accidents/MCO_report.pdf

Reply on news.ycombinator.com