4 ms·
Exactly
by alexbanks 6y ago
Exactly
- kerkeslager 6y agoAnalogies are a great way to explain things, but not so much a great way to prove things. If you're writing software that's life and death critical like wearing a seatbelt, you should absolutely be using a strong, statically typed language, because catching errors at runtime is completely unacceptable. But incidentally, none of the proponents of static types on this thread have talked about any languages that I would actually use for this situation. Java or C-family languages certainly aren't strongly typed enough. Type systems aren't a magic bullet. But in the vast majority of modern software, it mostly just matters that you catch and fix bugs quickly--whether you catch those bugs at compile time or runtime is usually not as critical.
- pavel_lishin 6y ago> Analogies are a great way to explain things, but not so much a great way to prove things. What are we proponents of static types being asked to prove? > But in the vast majority of modern software, it mostly just matters that you catch and fix bugs quickly--whether you catch those bugs at compile time or runtime is usually not as critical. I would argue that catching bugs at compile time, before you ship them, is vastly preferable to catching them at run time.
- kerkeslager 6y ago> What are we proponents of static types being asked to prove? Your arguments for why you think static types are better. > I would argue that catching bugs at compile time, before you ship them, is vastly preferable to catching them at run time. I would argue that you're only doing the benefit part of a cost-benefit analysis, which isn't very useful.