9 ms·

> The fact that both errors ocurred while using statically typed languages shows that Obviously it doesn't, since you can make a statically typed language prog

> The fact that both errors ocurred while using statically typed languages shows that Obviously it doesn't, since you can make a statically typed language program where every variable is a string map and every function takes variable args, and have no help from your compiler at any time because every type is always the right type. Sounds stupid, but in fact this is what happened in the examples. The examples are bona fide type errors, because even though a statically typed language is used, multiple different types of numbers got the same static type causing the issue. So the people here were offered the solution to their problem from their domain (two types of numbers), choose to use dynamic typing (make both a float even though they're different things), causing the compiler to have no way of statically checking their code, and that caused a bug. It's the opposite of a counter example. It is in fact the absence of enough typing that caused these issues. How much more typing do you need :)

Draiken 3y ago
In other words: types were not a deciding factor. Ultimately bugs cannot be prevented by having a type system. We make mistakes regardless of static or dynamic types. We can argue it's because of the lack of types, tests, oversight and so on. I'd argue nothing can force a programmer to design a perfect system. >The examples are bona fide type errors I'd disagree because those are logical errors. You can represent those as different types with a type system, but you could also not use a type system and convert those values properly. Whether we represent them as different types or not is an implementation choice. Those can be considered "type errors" (or missing types? a type of primitive obsession?) in a typed language. But it's still an issue with the implementation's logic.
- vouwfietsman 3y ago
  In other words: the seatbelt is not a deciding factor. Ultimately deaths cannot be prevented by seatbelts. People will die regardless whether they wear a seatbelt or not. We can argue its because of a lack of seatbelts, roll cages, airbags and so on. I'd argue nothing can force force a person to be perfectly safe while driving. > The examples are bona fide safety issues I'd disagree because those are driving errors. You can present those as cars missing safety features, but you could also not use those safety systems and just drive carefully. Whether we use safety systems or not is a design choice. Those can be considered "safety issues" (or missing safety? a type of safety obsession?) in a safety design perspective. But it's still an issue with the driver's behavior. bit of hyperbole for flavour: If we could just ditch the heavy roll cage, we could go much faster!
  - Draiken 3y ago
    I don't see how this adds to the discussion. Second time this week for me where people are connecting programing discussions with people dying. But sure, let's pretend this is a real argument. Typed languages are not at all like seatbelts. They aren't an easy safety feature you can use within a second and suddenly X% of bugs are prevented. No research shows that it prevents the bugs we actually care about, and they don't deal with runtime issues that actually kills people like the one discussed in this thread.
    - vouwfietsman 3y ago
      Ok let me make it more clear then: Type checking is a programming safety feature, and its trivial to argue in any domain that a safety feature is optional. Its always trivial to argue this because safety is never a functional requirement, so it is never guaranteed to be needed for anything, and its easy to point out that regardless of safety, mistakes will happen, and that safety does not prevent all mistakes. All of this is trivial, and can be applied to any safety measure, this is why I brought up seatbelts: to show that your argument depends strongly on the context of where the safety applies, and the sacrifices that have to be made to gain that safety. Which brings me to my second point: safety is always a tradeoff. Saying things like "perfectly safe" is completely void of meaning since nothing is ever perfectly safe, basing an argument on the fact that we cannot be perfectly safe is saying we shouldn't care about seatbelts because we're all gonna die anyway. Safety is a tradeoff and you should consider the up and downsides when you talk about it, always. So on your point: > They aren't an easy safety feature you can use within a second and suddenly X% of bugs are prevented Actually thats exactly what they are, because they will stop you from compiling a program that would have bugs in a dynamically typed system. Do they prevent all bugs? No, nobody is saying that. Its also easy to find how, just by googling: https://stackoverflow.com/a/27791387 https://stackoverflow.com/a/27791387 > No research shows that it prevents the bugs we actually care about No research shows anything about software, there is no research on software, stop deflecting. > they don't deal with runtime issues that actually kills people like the one discussed in this thread This thread is full of people suggesting type-safe fixes that would've prevented this, I'm not sure how you're still arguing that typing wouldn't help here. Again, maybe you don't want to use it because its too much work or some other kind of tradeoff you don't want to make, fine. But if you keep suggesting that types wouldn't work here you simply don't understand types.

Draiken 3y ago

In other words: types were not a deciding factor. Ultimately bugs cannot be prevented by having a type system. We make mistakes regardless of static or dynamic types. We can argue it's because of the lack of types, tests, oversight and so on. I'd argue nothing can force a programmer to design a perfect system. >The examples are bona fide type errors I'd disagree because those are logical errors. You can represent those as different types with a type system, but you could also not use a type system and convert those values properly. Whether we represent them as different types or not is an implementation choice. Those can be considered "type errors" (or missing types? a type of primitive obsession?) in a typed language. But it's still an issue with the implementation's logic.

vouwfietsman 3y ago
In other words: the seatbelt is not a deciding factor. Ultimately deaths cannot be prevented by seatbelts. People will die regardless whether they wear a seatbelt or not. We can argue its because of a lack of seatbelts, roll cages, airbags and so on. I'd argue nothing can force force a person to be perfectly safe while driving. > The examples are bona fide safety issues I'd disagree because those are driving errors. You can present those as cars missing safety features, but you could also not use those safety systems and just drive carefully. Whether we use safety systems or not is a design choice. Those can be considered "safety issues" (or missing safety? a type of safety obsession?) in a safety design perspective. But it's still an issue with the driver's behavior. bit of hyperbole for flavour: If we could just ditch the heavy roll cage, we could go much faster!
- Draiken 3y ago
  I don't see how this adds to the discussion. Second time this week for me where people are connecting programing discussions with people dying. But sure, let's pretend this is a real argument. Typed languages are not at all like seatbelts. They aren't an easy safety feature you can use within a second and suddenly X% of bugs are prevented. No research shows that it prevents the bugs we actually care about, and they don't deal with runtime issues that actually kills people like the one discussed in this thread.
  - vouwfietsman 3y ago
    Ok let me make it more clear then: Type checking is a programming safety feature, and its trivial to argue in any domain that a safety feature is optional. Its always trivial to argue this because safety is never a functional requirement, so it is never guaranteed to be needed for anything, and its easy to point out that regardless of safety, mistakes will happen, and that safety does not prevent all mistakes. All of this is trivial, and can be applied to any safety measure, this is why I brought up seatbelts: to show that your argument depends strongly on the context of where the safety applies, and the sacrifices that have to be made to gain that safety. Which brings me to my second point: safety is always a tradeoff. Saying things like "perfectly safe" is completely void of meaning since nothing is ever perfectly safe, basing an argument on the fact that we cannot be perfectly safe is saying we shouldn't care about seatbelts because we're all gonna die anyway. Safety is a tradeoff and you should consider the up and downsides when you talk about it, always. So on your point: > They aren't an easy safety feature you can use within a second and suddenly X% of bugs are prevented Actually thats exactly what they are, because they will stop you from compiling a program that would have bugs in a dynamically typed system. Do they prevent all bugs? No, nobody is saying that. Its also easy to find how, just by googling: https://stackoverflow.com/a/27791387 https://stackoverflow.com/a/27791387 > No research shows that it prevents the bugs we actually care about No research shows anything about software, there is no research on software, stop deflecting. > they don't deal with runtime issues that actually kills people like the one discussed in this thread This thread is full of people suggesting type-safe fixes that would've prevented this, I'm not sure how you're still arguing that typing wouldn't help here. Again, maybe you don't want to use it because its too much work or some other kind of tradeoff you don't want to make, fine. But if you keep suggesting that types wouldn't work here you simply don't understand types.