6 ms·

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

by ctz 10y ago

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.

banachtarski 10y ago
MCO?
- FigmentEngine 10y ago
  Mars Climate Orbiter http://sunnyday.mit.edu/accidents/MCO_report.pdf http://sunnyday.mit.edu/accidents/MCO_report.pdf
endorphone 10y ago
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.
- joshmarlow 10y ago
  > 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.
- marvy 10y ago
  > 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.
- cwzwarich 10y ago
  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#.
  - dwenzek 10y ago
    Thanks! I was aware of the feature but not of its author. https://blogs.msdn.microsoft.com/andrewkennedy/ https://blogs.msdn.microsoft.com/andrewkennedy/ https://channel9.msdn.com/Blogs/Charles/Andrew-Kennedy-F-Units-of-Measure https://channel9.msdn.com/Blogs/Charles/Andrew-Kennedy-F-Uni...
- dualogy 10y ago
  > 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"......
  - gpderetta 10y ago
    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.
    - pjmlp 10y ago
      The problem is getting embedded devs to use it, or when they do use it, not to write "C with C++ compiler" code.
      - gpderetta 10y ago
        of course, but it would be even harder to get them to use any other language other than C or C++.
- spc476 10y ago
  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.
  - dkersten 10y ago
    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/ https://frinklang.org/
btilly 10y ago
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.
- nickpsecurity 10y ago
  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.
  - btilly 10y ago
    This completely fits with the discussions that I had on the topic. However I have no idea how representative my random contacts were.
Qworg 10y ago
C/C++ is almost the only choice on most embedded systems, which is where most safety critical code lives.
- throwaway729 10y ago
  > 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".
  - Qworg 10y ago
    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.
    - throwaway729 10y ago
      > 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.
      - nerdponx 10y ago
        But the deep networks and such that power a self-driving car aren't written in C anyway. Or are they?
        10y ago
greenhouse_gas 10y ago
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))
- deleted 10y ago
  [deleted]
- jononor 10y ago
  Don't pass numbers between programs without units.
  - myst 10y ago
    Don't use non SI units.
    - Mikhail_Edoshin 10y ago
      People use non-SI units.
    - planteen 10y ago
      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).
  - greenhouse_gas 10y ago
    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.
AlexDenisov 10y ago
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.

by ctz 10y ago

banachtarski 10y ago

MCO?

FigmentEngine 10y ago
Mars Climate Orbiter http://sunnyday.mit.edu/accidents/MCO_report.pdf http://sunnyday.mit.edu/accidents/MCO_report.pdf

endorphone 10y ago

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.

joshmarlow 10y ago
> 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.
marvy 10y ago
> 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.
cwzwarich 10y ago
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#.
- dwenzek 10y ago
  Thanks! I was aware of the feature but not of its author. https://blogs.msdn.microsoft.com/andrewkennedy/ https://blogs.msdn.microsoft.com/andrewkennedy/ https://channel9.msdn.com/Blogs/Charles/Andrew-Kennedy-F-Units-of-Measure https://channel9.msdn.com/Blogs/Charles/Andrew-Kennedy-F-Uni...
dualogy 10y ago
> 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"......
- gpderetta 10y ago
  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.
  - pjmlp 10y ago
    The problem is getting embedded devs to use it, or when they do use it, not to write "C with C++ compiler" code.
    - gpderetta 10y ago
      of course, but it would be even harder to get them to use any other language other than C or C++.
spc476 10y ago
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.
- dkersten 10y ago
  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/ https://frinklang.org/

btilly 10y ago

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.

nickpsecurity 10y ago
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.
- btilly 10y ago
  This completely fits with the discussions that I had on the topic. However I have no idea how representative my random contacts were.

Qworg 10y ago

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

throwaway729 10y ago
> 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".
- Qworg 10y ago
  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.
  - throwaway729 10y ago
    > 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.
    - nerdponx 10y ago
      But the deep networks and such that power a self-driving car aren't written in C anyway. Or are they?
      - 10y ago

greenhouse_gas 10y ago

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))

deleted 10y ago
[deleted]
jononor 10y ago
Don't pass numbers between programs without units.
- myst 10y ago
  Don't use non SI units.
  - Mikhail_Edoshin 10y ago
    People use non-SI units.
  - planteen 10y ago
    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).
- greenhouse_gas 10y ago
  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.

AlexDenisov 10y ago

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.