3 ms·

This is beyond stupid. There is no such thing as "safe language". The author has clearly never seen what real safety critical code look like. When safety/rob

This is beyond stupid. There is no such thing as "safe language". The author has clearly never seen what real safety critical code look like. When safety/robustness really is critical, there are ways to achieve it with high confidence, and it can be done in any language as long as the team doing it is qualified and applying stringent rules. Of course this is time consuming and costly but luckily we've known how to do it for decades. The kind of rules I am talking about are more stringent than most people who never worked on those fields realize. In the most extreme case I've seen (aerospace code) the rules were : no dynamic memory allocation, no loop, no compiler. Yeah, pure hand-rolled assembly. Not for speed, for safety and predictability.

deleted 4y ago
[deleted]
benreesman 4y ago
Quality is costly in time and money, but to your point, it’s not mysterious how to achieve. I write slow, half-assed Python scripts every single day, because “good enough” is in fact good enough for some things. But over-extrapolating the “good enough” mindset to everything is lazy and makes computers less fun.
Avshalom 4y ago
For example, the specification framework for the C language by Andronick et al8 does not support "references to local variables, goto statements, expressions with uncontrolled side-effects, switch statements using fall-through, unions, floating point arithmetic, or calls to function pointers". If someone does not want to use a language which provides for bounds checks, due to a lack of some sort of "capability", then we cannot imagine that they will want to use any subset of C that can be formally modelled! that said this isn't an essay about safety, it's about the emotional appeal of a sort of false simplicity that some programmers are prone to falling for and pointing out the inherent inability of a couple projects (in synecdoche for a whole shit ton of other projects) to live up to promises of that mirage.
- stephc_int13 4y ago
  I think it's about the emotional appeal of a sort of false safety that some programmers are prone to falling for.
avgcorrection 4y ago
- stephc_int13 4y ago
  What I am saying is that when safety is required, there are known techniques to achieve it, but this is mostly about people and their skills, much more than tools. I am upset reading ignorant people talking about computer security without any real knowledge about it. This guy don't know what he is talking about. The fact that you can tag some part of the code as [unsafe] does not make the rest of the program better of "safe", this is magical thinking at best.
  - burntsushi 4y ago
    > The fact that you can tag some part of the code as [unsafe] does not make the rest of the program better of "safe", this is magical thinking at best. Good thing nobody is claiming that then. Let's see you try to actually articulate the argument being put forward instead of putting up a straw man. Here's a hint for where to start: describe the difference in safety (with respect to whether undefined behavior occurs) between a language like C++ and Rust.
    - stephc_int13 4y ago
      Describe the difference in safety between C++ and Rust : none Same as between assembly and Basic or Java and Perl.
      - burntsushi 4y ago
        Interesting. It's hard to take that claim seriously, given that Rust's entire design is based around the idea that any code you write outside of 'unsafe' blocks should be free from UB. And that the only way you can introduce UB into your code is by writing an 'unsafe' block. Contrast that with C++ where UB can be introduced anywhere in your code. The only thing I can think of is that you're using a different definition of 'safety' than everyone else. Which is fine, you can define words however you wish. But that's why I specifically included "with respect to whether undefined behavior occurs," in my comment, to avoid that kind of definitional misunderstanding. So perhaps you just didn't read my comment carefully enough. But yeah, if you think there is literally no difference in safety between Assembly and Java, then I'd probably call that "totally and completely nutso." It's nuts enough that I don't think any kind of asynchronous discussion could fix it. Next time, lead with that statement, so that everyone else reading along can calibrate their expectations for just how seriously they should take you. :-) The other interesting bit here is that I was effectively asking for a steel man. But instead, you just decided to give your own answer to the question. So either you misunderstood that too, or you just literally don't have any idea what other people are actually claiming.
tayistay 4y ago
Safety can be formally defined in various ways. See https://cs.stackexchange.com/questions/93798/what-is-a-safe-programming-language https://cs.stackexchange.com/questions/93798/what-is-a-safe-... for a decent overview. The article is likely referring to memory safety.

deleted 4y ago

[deleted]

benreesman 4y ago

Quality is costly in time and money, but to your point, it’s not mysterious how to achieve. I write slow, half-assed Python scripts every single day, because “good enough” is in fact good enough for some things. But over-extrapolating the “good enough” mindset to everything is lazy and makes computers less fun.

Avshalom 4y ago

For example, the specification framework for the C language by Andronick et al8 does not support "references to local variables, goto statements, expressions with uncontrolled side-effects, switch statements using fall-through, unions, floating point arithmetic, or calls to function pointers". If someone does not want to use a language which provides for bounds checks, due to a lack of some sort of "capability", then we cannot imagine that they will want to use any subset of C that can be formally modelled! that said this isn't an essay about safety, it's about the emotional appeal of a sort of false simplicity that some programmers are prone to falling for and pointing out the inherent inability of a couple projects (in synecdoche for a whole shit ton of other projects) to live up to promises of that mirage.

stephc_int13 4y ago
I think it's about the emotional appeal of a sort of false safety that some programmers are prone to falling for.

avgcorrection 4y ago

stephc_int13 4y ago
What I am saying is that when safety is required, there are known techniques to achieve it, but this is mostly about people and their skills, much more than tools. I am upset reading ignorant people talking about computer security without any real knowledge about it. This guy don't know what he is talking about. The fact that you can tag some part of the code as [unsafe] does not make the rest of the program better of "safe", this is magical thinking at best.
- burntsushi 4y ago
  > The fact that you can tag some part of the code as [unsafe] does not make the rest of the program better of "safe", this is magical thinking at best. Good thing nobody is claiming that then. Let's see you try to actually articulate the argument being put forward instead of putting up a straw man. Here's a hint for where to start: describe the difference in safety (with respect to whether undefined behavior occurs) between a language like C++ and Rust.
  - stephc_int13 4y ago
    Describe the difference in safety between C++ and Rust : none Same as between assembly and Basic or Java and Perl.
    - burntsushi 4y ago
      Interesting. It's hard to take that claim seriously, given that Rust's entire design is based around the idea that any code you write outside of 'unsafe' blocks should be free from UB. And that the only way you can introduce UB into your code is by writing an 'unsafe' block. Contrast that with C++ where UB can be introduced anywhere in your code. The only thing I can think of is that you're using a different definition of 'safety' than everyone else. Which is fine, you can define words however you wish. But that's why I specifically included "with respect to whether undefined behavior occurs," in my comment, to avoid that kind of definitional misunderstanding. So perhaps you just didn't read my comment carefully enough. But yeah, if you think there is literally no difference in safety between Assembly and Java, then I'd probably call that "totally and completely nutso." It's nuts enough that I don't think any kind of asynchronous discussion could fix it. Next time, lead with that statement, so that everyone else reading along can calibrate their expectations for just how seriously they should take you. :-) The other interesting bit here is that I was effectively asking for a steel man. But instead, you just decided to give your own answer to the question. So either you misunderstood that too, or you just literally don't have any idea what other people are actually claiming.

tayistay 4y ago

Safety can be formally defined in various ways. See https://cs.stackexchange.com/questions/93798/what-is-a-safe-programming-language https://cs.stackexchange.com/questions/93798/what-is-a-safe-... for a decent overview. The article is likely referring to memory safety.