4 ms·

> 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 passa

> 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
        I haven't worked in Python, so I can't speak to what Python programmers typically do. But I would much rather get an intelligible error like "you passed a float to the doMath function when it expects an int" or even "the 1st argument to the doWork method must implement the toFoo method" than that kind of error, because the fix is immediate and obvious. I'd prefer that even if we're talking about something that isn't really "library code." It may well be true that most people with this kind of view gravitate away from working in Python; I certainly hated working in Ruby.
        andybak 9y ago
        Maybe that's it. That error is fairly obvious to me but I admit in some cases you have to traverse the call stack to figure out where the incorrect value got introduced. I still feel I'd prefer the occasional inconvenience in tracking down a bug over some of the pain I've experienced in trying to adapt my brain to a statically typed language. As another poster commented it really only makes sense to compare a cutting edge dynamically-typed language with a cutting edge statically-typed language if you want to debate the strengths and weaknesses of each. Otherwise you're just comparing specific language weaknesses and strengths.

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
      I haven't worked in Python, so I can't speak to what Python programmers typically do. But I would much rather get an intelligible error like "you passed a float to the doMath function when it expects an int" or even "the 1st argument to the doWork method must implement the toFoo method" than that kind of error, because the fix is immediate and obvious. I'd prefer that even if we're talking about something that isn't really "library code." It may well be true that most people with this kind of view gravitate away from working in Python; I certainly hated working in Ruby.
      - andybak 9y ago
        Maybe that's it. That error is fairly obvious to me but I admit in some cases you have to traverse the call stack to figure out where the incorrect value got introduced. I still feel I'd prefer the occasional inconvenience in tracking down a bug over some of the pain I've experienced in trying to adapt my brain to a statically typed language. As another poster commented it really only makes sense to compare a cutting edge dynamically-typed language with a cutting edge statically-typed language if you want to debate the strengths and weaknesses of each. Otherwise you're just comparing specific language weaknesses and strengths.