4 ms·

What language makes it impossible to write if parse(config) == false then reboot?

thirtyseven 6y ago
In this case the XML file parsed fine, but the contents (specifically an empty element that the firmware expected to be populated) caused a crash.
- tedunangst 6y ago
  I guess I should rephrase. What language makes it impossible to call abort() after a required XML element is found to be missing?
  - renewiltord 6y ago
    Presumably languages which default to optional instead of null with the default ergonomics being to “or_else” instead of “unwrap” will encourage safer error handling. It works for me, but I don’t know if it is yet well known what the effect of developer UX on error rate is.
    - stefan_ 6y ago
      Nope, you are still not making sense. Just look at the "Facebook remotely disables all apps" issue. Both times it was issues deserializing - the deserialization wasn't unsafe or outright crashing, it was simply the SDK wasn't prepared to deal with the data it got.
      - renewiltord 6y ago
        I find that I can write code that is less likely to crash or fail more easily in some languages than in others. If this is not the case for you, I understand that it isn't compelling but that's okay. Not particularly looking for you to adopt anything. UX things in some languages guide me to idiomatic code that is safer. And as engineers, we know there is no guarantee, only shades of improvement. But again, if language choice does not affect your program quality, so be it.
_ph_ 6y ago
Impossible is a big word :). But while a C or C++ program tends to crash in the presence of an error, like with a segfault, a lot of languages just throw an error which you can catch. So you could proceed with the default values, if the file cannot be read correctly.
- kjs3 6y ago
  Oh please. C and C++ programs can be coded to fail gracefully and "a lot of languages" fail in unpredictable and unfortunate ways and shitty programmers still don't catch those magic errors. This is a matter of crappy engineering, not per se crappy language.
  - _ph_ 6y ago
    You can have programs crash in any language. However, it is the question, how well a program can recover from an error. Having a concept of error handlers in the language, which can catch conditions occuring inside the code they are calling, leads to more robust programmers. Think of it as airbags and seat belts. Drivers, who don't make a mistake, wouldn't need them, but in reality shit happens, and they give us more survival chances.
- rndgermandude 6y ago
  "can catch" doesn't give you anything, unless you actually do the catching. C and C++ programs tend to crash in the presence of an error, but so do rust programs (panic), C# and java and js and python programs (unhandled exception). Some languages make it harder to footgun yourself for certain types of errors, but never all types of errors. I have seen js programs (and similar stuff in other languages) crash because of something like JSON.parse(response).list[0].string.length where the response was valid json, just the .list property was an empty array (or even undefined because omitted in the json). Does rust protect from such mistakes (because I know some people on here like to claim rust is the answer to everything)? Verbatim from their docs: let v = vec![0, 2, 4, 6]; println!("{}", v[6]); // it will panic! I'd guess it's exactly such type of bounds error at play with the Saumsung thing, from the mention of that empty <list/> element in the article. I have written such code myself because I was lazy or distracted or "need performance" or "this can never be empty per spec" or "oops, my range calculation was off by one", tho luckily I didn't outright brick anything, yet.
billforsternz 6y ago
if !parse(config) then reboot. Please, for the love of God.
- rad_gruchalski 6y ago
  I’m sorry but I find ruby „reboot unless config.parse?” much more readable here.
  - billforsternz 6y ago
    You can argue about which syntax is best. But irrespective, having a perfectly good boolean already, but then comparing it to true or false to unnecessarily create another boolean is always just wrong.

In this case the XML file parsed fine, but the contents (specifically an empty element that the firmware expected to be populated) caused a crash.

tedunangst 6y ago
I guess I should rephrase. What language makes it impossible to call abort() after a required XML element is found to be missing?
- renewiltord 6y ago
  Presumably languages which default to optional instead of null with the default ergonomics being to “or_else” instead of “unwrap” will encourage safer error handling. It works for me, but I don’t know if it is yet well known what the effect of developer UX on error rate is.
  - stefan_ 6y ago
    Nope, you are still not making sense. Just look at the "Facebook remotely disables all apps" issue. Both times it was issues deserializing - the deserialization wasn't unsafe or outright crashing, it was simply the SDK wasn't prepared to deal with the data it got.
    - renewiltord 6y ago
      I find that I can write code that is less likely to crash or fail more easily in some languages than in others. If this is not the case for you, I understand that it isn't compelling but that's okay. Not particularly looking for you to adopt anything. UX things in some languages guide me to idiomatic code that is safer. And as engineers, we know there is no guarantee, only shades of improvement. But again, if language choice does not affect your program quality, so be it.

_ph_ 6y ago

Impossible is a big word :). But while a C or C++ program tends to crash in the presence of an error, like with a segfault, a lot of languages just throw an error which you can catch. So you could proceed with the default values, if the file cannot be read correctly.

kjs3 6y ago
Oh please. C and C++ programs can be coded to fail gracefully and "a lot of languages" fail in unpredictable and unfortunate ways and shitty programmers still don't catch those magic errors. This is a matter of crappy engineering, not per se crappy language.
- _ph_ 6y ago
  You can have programs crash in any language. However, it is the question, how well a program can recover from an error. Having a concept of error handlers in the language, which can catch conditions occuring inside the code they are calling, leads to more robust programmers. Think of it as airbags and seat belts. Drivers, who don't make a mistake, wouldn't need them, but in reality shit happens, and they give us more survival chances.
rndgermandude 6y ago
"can catch" doesn't give you anything, unless you actually do the catching. C and C++ programs tend to crash in the presence of an error, but so do rust programs (panic), C# and java and js and python programs (unhandled exception). Some languages make it harder to footgun yourself for certain types of errors, but never all types of errors. I have seen js programs (and similar stuff in other languages) crash because of something like JSON.parse(response).list[0].string.length where the response was valid json, just the .list property was an empty array (or even undefined because omitted in the json). Does rust protect from such mistakes (because I know some people on here like to claim rust is the answer to everything)? Verbatim from their docs: let v = vec![0, 2, 4, 6]; println!("{}", v[6]); // it will panic! I'd guess it's exactly such type of bounds error at play with the Saumsung thing, from the mention of that empty <list/> element in the article. I have written such code myself because I was lazy or distracted or "need performance" or "this can never be empty per spec" or "oops, my range calculation was off by one", tho luckily I didn't outright brick anything, yet.

billforsternz 6y ago

if !parse(config) then reboot. Please, for the love of God.

rad_gruchalski 6y ago
I’m sorry but I find ruby „reboot unless config.parse?” much more readable here.
- billforsternz 6y ago
  You can argue about which syntax is best. But irrespective, having a perfectly good boolean already, but then comparing it to true or false to unnecessarily create another boolean is always just wrong.