4 ms·

Assuming your analogy has merit, I doubt very much this is true. Computer modelling, for example, has improved significantly over the years. However, it is tru

Assuming your analogy has merit, I doubt very much this is true. Computer modelling, for example, has improved significantly over the years. However, it is true that many high profile failures in aerospace have been due to software errors, so I would say that software tooling is certainly one area that they could also benefit from.

fooker 9y ago
In line with your reasoning, software development methodology has significantly improved over the years. One does not write C++ in 2018 as they would have written C in 1980.
- willtim 9y ago
  Best practice has changed, but C++ does not enforce it. Did Samsung follow best practices with Tizen? Languages like Rust and Haskell are an attempt to put such best practice into the language tooling.
  - fooker 9y ago
    >Languages like Rust and Haskell are an attempt to put such best practice into the language tooling. Best practice often varies between projects and changes rather often, ..say.. in a matter of a few years. Most of what Haskell and Rust offer are a library away (yes, even compile time checks) for C++, but not vice versa. There is a reason new languages with baked in 'opinion' come and go.
    - willtim 9y ago
      You cannot make C++ secure and safe with a library.
      - fooker 9y ago
        If you state your criteria for 'safe' and 'secure', I can point you towards library implementations for each of your points. You can not stop the users from shooting themselves in the foot, but that is not the goal here. We want to enable 'safe and secure' programming, not develop toy idiot-proof write-only languages that are useless for large projects.
        willtim 9y ago
        > You can not stop the users from shooting themselves in the foot, but that is not the goal here. It should be the goal. Even experts make mistakes. This is why static type systems exist. The logical thing to do is to strengthen the type system to prevent more classes of errors.
        fooker 9y ago
        And yet you always need to provide users an way out for the sake of pragmatism. Examples: Rust's unsafe block, Haskell's Unsafe.Coerce, etc. If the user avoids the analogous features in C++ and stick to modern conventions, it is not less safe/secure.
  - UncleMeat 9y ago
    You'd have to be insane to want to implement an os in Haskell.

fooker 9y ago

In line with your reasoning, software development methodology has significantly improved over the years. One does not write C++ in 2018 as they would have written C in 1980.

willtim 9y ago
Best practice has changed, but C++ does not enforce it. Did Samsung follow best practices with Tizen? Languages like Rust and Haskell are an attempt to put such best practice into the language tooling.
- fooker 9y ago
  >Languages like Rust and Haskell are an attempt to put such best practice into the language tooling. Best practice often varies between projects and changes rather often, ..say.. in a matter of a few years. Most of what Haskell and Rust offer are a library away (yes, even compile time checks) for C++, but not vice versa. There is a reason new languages with baked in 'opinion' come and go.
  - willtim 9y ago
    You cannot make C++ secure and safe with a library.
    - fooker 9y ago
      If you state your criteria for 'safe' and 'secure', I can point you towards library implementations for each of your points. You can not stop the users from shooting themselves in the foot, but that is not the goal here. We want to enable 'safe and secure' programming, not develop toy idiot-proof write-only languages that are useless for large projects.
      - willtim 9y ago
        > You can not stop the users from shooting themselves in the foot, but that is not the goal here. It should be the goal. Even experts make mistakes. This is why static type systems exist. The logical thing to do is to strengthen the type system to prevent more classes of errors.
        fooker 9y ago
        And yet you always need to provide users an way out for the sake of pragmatism. Examples: Rust's unsafe block, Haskell's Unsafe.Coerce, etc. If the user avoids the analogous features in C++ and stick to modern conventions, it is not less safe/secure.
- UncleMeat 9y ago
  You'd have to be insane to want to implement an os in Haskell.