4 ms·

Mars Climate Orbiter was lost because they forgot to convert units between different systems. That's an error that can (and probably would) be done in all type-

Mars Climate Orbiter was lost because they forgot to convert units between different systems. That's an error that can (and probably would) be done in all type-safe languages I know of.

fiedzia 10y ago
It could be prevented if you could express units in the type system. Declare numeric_value_in_meters and numeric_value_in_yards as types and problem solved. Sure, it still possible that someone would not do that, but having this option is statistically better than not having.
- mikulas_florek 10y ago
  You can do that in C struct Meters { int value; }
  - fiedzia 10y ago
    Yes, but nothing will stop you from casting pointer to meters into pointer to yards, while many C features force or encourage this behaviour. You also cannot override operators for combining those units. And the value is still just int.
    - mikulas_florek 10y ago
      > casting pointer to meters into pointer to yards, while many C features force or encourage this behaviour. What C feature forces or encourages casting Meters* to Yards*? > You also cannot override operators for combining those units. The lack of operator overloads has nothing to do with typesafety. There are languages which are considered typesafe and which do not have operator overloading.
  - jasode 10y ago
    No, it's not statically checked for correctness. Example of successful compilation in C Language which is semantically wrong: http://ideone.com/Hdd4Sh http://ideone.com/Hdd4Sh (No casts required.)
    - mikulas_florek 10y ago
      It's hard to discuss this without using any specific "type-safe" language. 1. you can have the same problem in type-safe language, since it will probably have cast to int too 2. do not use builtin operators in C for that, instead create new functions, e.g. addMeters(Meters a, Meters b); 3. hide the int in *.c file
      - fiedzia 10y ago
        > you can have the same problem in type-safe language Yes, you can. But at least you have a better option and better chance of other people using it, so statistically you'll have less errors. > do not use builtin operators in C for that No, do not add another rule to a million of rules people have to already follow, make compiler worry about enforcing that, not developer.
        mikulas_florek 10y ago
        > Yes, you can. But at least you have a better option and better chance of other people using it, so statistically you'll have less errors. I highly doubt that this specific bug would not happen in any typesafe language. The only way I see this not happening is if there is no native float-like type. Is there such language? They could have make it safe in C, and they did not, probably because it's convenient to use float. > No, do not add another rule to a million of rules people have to already follow, make compiler worry about enforcing that, not developer. It can be implemented in C so it's forced by compiler.
      - jasode 10y ago
        Look at the common theme among your suggestions: - do not use builtin operators in C for that, - instead create new functions, e.g. addMeters() - hide the int in *.c file Those are "best practices" instead of compiler-enforced type-check errors. Likewise, suggesting a best practice such as "don't free() memory twice" is not the same as a GC-language (Lisp/Java/C#/Go) freeing memory on the programmer's behalf or a static-ownership checker (Rust) preventing a programmer from making that mistake.
  - JoachimSchipper 10y ago
    Yes, although you should probably do struct value_in_meters { int in_meters; }, so that e.g. x.in_meters / y.in_inches (will compile, but) looks as wrong as it is.
muraiki 10y ago
F# supports units of measure: https://fsharpforfunandprofit.com/posts/units-of-measure/ https://fsharpforfunandprofit.com/posts/units-of-measure/
- mikulas_florek 10y ago
  That looks useful. I do not know F#, but can't you still use ordinary float and have the same bug?
  - kazagistar 10y ago
    Sure, unit wrappers are much more like "memory safety checks" in C, in that they are incomplete and can be bypassed. In that sense, the war against raw types is necessarily a cultural one.

Mars Climate Orbiter was lost because they forgot to convert units between different systems. That's an error that can (and probably would) be done in all type-safe languages I know of.

fiedzia 10y ago

It could be prevented if you could express units in the type system. Declare numeric_value_in_meters and numeric_value_in_yards as types and problem solved. Sure, it still possible that someone would not do that, but having this option is statistically better than not having.

mikulas_florek 10y ago
You can do that in C struct Meters { int value; }
- fiedzia 10y ago
  Yes, but nothing will stop you from casting pointer to meters into pointer to yards, while many C features force or encourage this behaviour. You also cannot override operators for combining those units. And the value is still just int.
  - mikulas_florek 10y ago
    > casting pointer to meters into pointer to yards, while many C features force or encourage this behaviour. What C feature forces or encourages casting Meters* to Yards*? > You also cannot override operators for combining those units. The lack of operator overloads has nothing to do with typesafety. There are languages which are considered typesafe and which do not have operator overloading.
- jasode 10y ago
  No, it's not statically checked for correctness. Example of successful compilation in C Language which is semantically wrong: http://ideone.com/Hdd4Sh http://ideone.com/Hdd4Sh (No casts required.)
  - mikulas_florek 10y ago
    It's hard to discuss this without using any specific "type-safe" language. 1. you can have the same problem in type-safe language, since it will probably have cast to int too 2. do not use builtin operators in C for that, instead create new functions, e.g. addMeters(Meters a, Meters b); 3. hide the int in *.c file
    - fiedzia 10y ago
      > you can have the same problem in type-safe language Yes, you can. But at least you have a better option and better chance of other people using it, so statistically you'll have less errors. > do not use builtin operators in C for that No, do not add another rule to a million of rules people have to already follow, make compiler worry about enforcing that, not developer.
      - mikulas_florek 10y ago
        > Yes, you can. But at least you have a better option and better chance of other people using it, so statistically you'll have less errors. I highly doubt that this specific bug would not happen in any typesafe language. The only way I see this not happening is if there is no native float-like type. Is there such language? They could have make it safe in C, and they did not, probably because it's convenient to use float. > No, do not add another rule to a million of rules people have to already follow, make compiler worry about enforcing that, not developer. It can be implemented in C so it's forced by compiler.
    - jasode 10y ago
      Look at the common theme among your suggestions: - do not use builtin operators in C for that, - instead create new functions, e.g. addMeters() - hide the int in *.c file Those are "best practices" instead of compiler-enforced type-check errors. Likewise, suggesting a best practice such as "don't free() memory twice" is not the same as a GC-language (Lisp/Java/C#/Go) freeing memory on the programmer's behalf or a static-ownership checker (Rust) preventing a programmer from making that mistake.
- JoachimSchipper 10y ago
  Yes, although you should probably do struct value_in_meters { int in_meters; }, so that e.g. x.in_meters / y.in_inches (will compile, but) looks as wrong as it is.

muraiki 10y ago

F# supports units of measure: https://fsharpforfunandprofit.com/posts/units-of-measure/ https://fsharpforfunandprofit.com/posts/units-of-measure/

mikulas_florek 10y ago
That looks useful. I do not know F#, but can't you still use ordinary float and have the same bug?
- kazagistar 10y ago
  Sure, unit wrappers are much more like "memory safety checks" in C, in that they are incomplete and can be bypassed. In that sense, the war against raw types is necessarily a cultural one.