6 ms·

> Prefer using languages with type systems for writing code that needs to be correct. If your language does not have a type system, defensively check that the d

> Prefer using languages with type systems for writing code that needs to be correct. If your language does not have a type system, defensively check that the data you’ve been passed is correct at runtime, and throw an error if it isn’t. Hmmmm. Several decades of nuanced debate summarised inaccurately in one neat little hand-wavy paragraph.

emodendroket 9y ago
Can there really be any serious debate about the idea that type-checking increases the likelihood of correct code? Pretty much all the arguments against it have to do with other things; I've never heard anyone claim untyped code is more likely to be correct.
- andybak 9y ago
  > Can there really be any serious debate about the idea that type-checking increases the likelihood of correct code? I agree. I didn't say otherwise. The passage I quoted said "prefer using languages with type systems for writing code that needs to be correct" which seemed fairly sweeping to me. Those "other things" you mention sometimes matter a lot. I also to a lesser degree take issue with "If your language does not have a type system, defensively check that the data you’ve been passed is correct at runtime, and throw an error if it isn’t." - this seems like a fairly overly strict guideline. Most tests will check types as a side-effect of whatever they are doing. And the advice to add runtime type guards into every piece of code I write is worse than telling me to just switching to a explicitly typed language.
  - emodendroket 9y ago
    In general, I agree with the advice. Even in some typed languages, like C#, it can make sense to open methods with guards like `if (someArg == null) {throw new InvalidArgumentException();}`. If your code is making some assumption about its input, it should validate that that assumption is true rather than assuming nobody will call it the wrong way, most of the time. Maybe if you're writing Ruby you'll check if the object responds to a particular method call rather than explicitly checking the type, but the principle is the same.
    - andybak 9y ago
      > If your code is making some assumption about its input, it should validate that that assumption is true rather than assuming nobody will call it the wrong way This kills readability. Stuff like that belongs in tests. Code should express the intent and logic and anything extraneous should be abstracted away or not be there at all. Code should aspire to reading like pseudocode.
      - dragonwriter 9y ago
        If its “private” code that is not externally exposed, that may be tolerable though it increases coupling and may harm maintainability, especially if the system is large enough to have different teams supporting the function vs. some or all of the call sites. If it is publicly exposed, you are more likely to need to validate assumptions (if they aren't statically enforced), otherwise you are prone to creating undefined behavior.
      - emodendroket 9y ago
        How are tests supposed to prevent new callers from violating the assumptions?
        andybak 9y ago
        I wasn't thinking about library code but I guess that's a fair point. However I just don't recall this being enough of a problem in real world situations. And I don't recall many Python libraries that bother to do this. I just looked through a few stdlib functions and other popular libraries and I'm not seeing much trace of validity checking as a standard working practice: > from random import randint > randint(1, "strawberry") TypeError: cannot concatenate 'str' and 'int' objects This fails further down the stack - and would succeed for any types that allow addition with an int (and might fail somewhere further on in those cases) This aligns with Python's encouragement of duck typing but directly contradicts what you seem to be claiming as a universal best practice?
        emodendroket 9y ago

emodendroket 9y ago

Can there really be any serious debate about the idea that type-checking increases the likelihood of correct code? Pretty much all the arguments against it have to do with other things; I've never heard anyone claim untyped code is more likely to be correct.

andybak 9y ago
> Can there really be any serious debate about the idea that type-checking increases the likelihood of correct code? I agree. I didn't say otherwise. The passage I quoted said "prefer using languages with type systems for writing code that needs to be correct" which seemed fairly sweeping to me. Those "other things" you mention sometimes matter a lot. I also to a lesser degree take issue with "If your language does not have a type system, defensively check that the data you’ve been passed is correct at runtime, and throw an error if it isn’t." - this seems like a fairly overly strict guideline. Most tests will check types as a side-effect of whatever they are doing. And the advice to add runtime type guards into every piece of code I write is worse than telling me to just switching to a explicitly typed language.
- emodendroket 9y ago
  In general, I agree with the advice. Even in some typed languages, like C#, it can make sense to open methods with guards like `if (someArg == null) {throw new InvalidArgumentException();}`. If your code is making some assumption about its input, it should validate that that assumption is true rather than assuming nobody will call it the wrong way, most of the time. Maybe if you're writing Ruby you'll check if the object responds to a particular method call rather than explicitly checking the type, but the principle is the same.
  - andybak 9y ago
    > If your code is making some assumption about its input, it should validate that that assumption is true rather than assuming nobody will call it the wrong way This kills readability. Stuff like that belongs in tests. Code should express the intent and logic and anything extraneous should be abstracted away or not be there at all. Code should aspire to reading like pseudocode.
    - dragonwriter 9y ago
      If its “private” code that is not externally exposed, that may be tolerable though it increases coupling and may harm maintainability, especially if the system is large enough to have different teams supporting the function vs. some or all of the call sites. If it is publicly exposed, you are more likely to need to validate assumptions (if they aren't statically enforced), otherwise you are prone to creating undefined behavior.
    - emodendroket 9y ago
      How are tests supposed to prevent new callers from violating the assumptions?
      - andybak 9y ago
        I wasn't thinking about library code but I guess that's a fair point. However I just don't recall this being enough of a problem in real world situations. And I don't recall many Python libraries that bother to do this. I just looked through a few stdlib functions and other popular libraries and I'm not seeing much trace of validity checking as a standard working practice: > from random import randint > randint(1, "strawberry") TypeError: cannot concatenate 'str' and 'int' objects This fails further down the stack - and would succeed for any types that allow addition with an int (and might fail somewhere further on in those cases) This aligns with Python's encouragement of duck typing but directly contradicts what you seem to be claiming as a universal best practice?
        emodendroket 9y ago