2 ms·

Reduces bugs in size, or only leaves smaller bugs behind? These are two very different outcomes. If the remaining bugs are unrelated to the class of bugs that

Reduces bugs in size, or only leaves smaller bugs behind? These are two very different outcomes. If the remaining bugs are unrelated to the class of bugs that were eliminated entirely, then the difficulty in finding them has little bearing on the outcome, since we’re now talking about an entirely different class of bugs.

moffkalast 4y ago
This is conjecture, but in my experience you'd get the following: - in JS, your code will run with the bug then do something catastrophic during runtime that you can then notice and trace to the core issue - in Java it won't compile, so you fix it so it compiles and runs, then it'll hit you in like 2 hours of runtime with a NPE or something and you'll have no idea what caused it Maybe Kotlin, Rust, and the like solve that sort of thing better but I've yet to be convinced.
- haswell 4y ago
  But is there any evidence that the NPE would have blown up catastrophically without type checking? Is the NPE even related to type checking? It seems you're describing an orthogonal issue, and it's unclear why type checking is a Bad Thing or even related to the NPE at all. Let's say I work on an assembly line, and must place physical parts into a machine that assembles a larger part. There are many ways this machine can break down - I could put the wrong parts in, leading to a complete failure, or some part of the machine could malfunction independently. - We could implement part validation on the assembly machine to make sure it's impossible to insert the wrong parts. This eliminates failures related to incorrect part insertion. - Unrelated to this, a drive belt starts to wear out and slips every so often, leading to a slight slowdown in a conveyor belt, which ultimately leads to a botched item. The way I read your argument, you would say that part validation is bad, because it's easier to diagnose a meltdown when incorrect parts are inserted by the operator than it is to determine that the drive belt is slipping. Except the drive belt slipping is not related to operator error, and would have happened whether part validation was happening or not. This is hopefully obviously nonsensical - better to reduce the overall error rate by implementing part validation than to leave two avenues for error. Before part validation, the machine could fail because of operator error (common) or drive belt failure (uncommon). After part validation, only the uncommon error occurs. This is better than no validation at all, even if drive belt failure is harder to identify than the machine screeching to a halt when the wrong parts are inserted. What am I missing?

moffkalast 4y ago

This is conjecture, but in my experience you'd get the following: - in JS, your code will run with the bug then do something catastrophic during runtime that you can then notice and trace to the core issue - in Java it won't compile, so you fix it so it compiles and runs, then it'll hit you in like 2 hours of runtime with a NPE or something and you'll have no idea what caused it Maybe Kotlin, Rust, and the like solve that sort of thing better but I've yet to be convinced.

haswell 4y ago
But is there any evidence that the NPE would have blown up catastrophically without type checking? Is the NPE even related to type checking? It seems you're describing an orthogonal issue, and it's unclear why type checking is a Bad Thing or even related to the NPE at all. Let's say I work on an assembly line, and must place physical parts into a machine that assembles a larger part. There are many ways this machine can break down - I could put the wrong parts in, leading to a complete failure, or some part of the machine could malfunction independently. - We could implement part validation on the assembly machine to make sure it's impossible to insert the wrong parts. This eliminates failures related to incorrect part insertion. - Unrelated to this, a drive belt starts to wear out and slips every so often, leading to a slight slowdown in a conveyor belt, which ultimately leads to a botched item. The way I read your argument, you would say that part validation is bad, because it's easier to diagnose a meltdown when incorrect parts are inserted by the operator than it is to determine that the drive belt is slipping. Except the drive belt slipping is not related to operator error, and would have happened whether part validation was happening or not. This is hopefully obviously nonsensical - better to reduce the overall error rate by implementing part validation than to leave two avenues for error. Before part validation, the machine could fail because of operator error (common) or drive belt failure (uncommon). After part validation, only the uncommon error occurs. This is better than no validation at all, even if drive belt failure is harder to identify than the machine screeching to a halt when the wrong parts are inserted. What am I missing?