4 ms·

Yea, this is why I posted it. To me it seems: - Small codebase. Fine, use both. - Medium codebase. Fine, use both. - Large codebase. You're definitely going

Yea, this is why I posted it. To me it seems: - Small codebase. Fine, use both. - Medium codebase. Fine, use both. - Large codebase. You're definitely going to have some typing bugs with dynamically typed languages. - Humongous codebase. You're definitely going to have many typing bugs with dynamically typed languages.

throwaway894345 6y ago
I'll say that we have a small-medium code base and we see lots and lots of dynamic typing errors in production every day. I would also say "even though we have lots of people who are experienced Python developers", but I think it's actually because we have so many developers who have only developed seriously in dynamically typed languages and don't "think in types" if you will.
- blackrock 6y ago
  Can’t you write the Python functions to force check the input parameter for its type? And error out if not. This should enable you to catch most errors immediately during development.
  - mixmastamyk 6y ago
    Yes, but easier to just write tests.
    - throwaway894345 6y ago
      And easier still just to use static types.
      - mixmastamyk 6y ago
        Often not, if the overhead of adding them outweighs their utility for the project.
  - throwaway894345 6y ago
    No, this doesn’t help at all. You only hit these errors if you run those paths in your tests, but those paths would already error downstream. Those paths that weren’t tested may still contain errors that go to production, and again you just hit your new type error instead of the downstream type error. What you need is something that can help you test more paths, and static type checking checks all paths. Further, they can check all paths without writing any tests (you should still have tests, but you need fewer with a static type system to keep your bug rate the same). Moreover, static type checkers catch errors almost immediately, so you get feedback about your errors sooner rather and more frequently, so you spend less time investing in code that will have to be rewritten. Lastly, they put rails on the code—it’s harder to write bad code including gratuitously magical or abstract code, so your coworkers aren’t writing as much bas code that you have to interface with. If you find static type systems to be frustrating, you’re probably the problematic coworker. :)
    - blackrock 6y ago
      I don’t disagree with you. Python seems to encourage poor development practices. Basically, anything goes. This can be problematic if you use other people’s libraries, and if their libraries are not fully vetted. This is not a Python problem, per se. It is a developer problem. It is a human problem. However, with your own code and libraries, you can enforce your own rigor. Keep your functions smaller, test all the inputs, and validate all the outputs. Although you may end up with smaller production code, but more unit tests. The unit tests are good, as they give you evidence that you did cover those corner cases. However, the good thing, is that if the functions are smaller, and well unit tested, then it becomes rare that you have to modify it at a later date. And especially if you think through all the different angles, and try to future proof it. Now you have the ability to do functional composition. Just keep chaining the outputs of one function into another.
gfodor 6y ago
well, sure. certainly one of the costs of a dynamic language is the possibility of typing bugs, and those will likely grow linearly with the size of the code base. the question is if those programs were written in statically typed languages, how the world would differ, in-full. for example, they may have been built faster or sloer. or they may have better or worse test coverage, affecting severe defect count overall. or you may have had to hire a different team, with tradeoffs. hard to say.

throwaway894345 6y ago

I'll say that we have a small-medium code base and we see lots and lots of dynamic typing errors in production every day. I would also say "even though we have lots of people who are experienced Python developers", but I think it's actually because we have so many developers who have only developed seriously in dynamically typed languages and don't "think in types" if you will.

blackrock 6y ago
Can’t you write the Python functions to force check the input parameter for its type? And error out if not. This should enable you to catch most errors immediately during development.
- mixmastamyk 6y ago
  Yes, but easier to just write tests.
  - throwaway894345 6y ago
    And easier still just to use static types.
    - mixmastamyk 6y ago
      Often not, if the overhead of adding them outweighs their utility for the project.
- throwaway894345 6y ago
  No, this doesn’t help at all. You only hit these errors if you run those paths in your tests, but those paths would already error downstream. Those paths that weren’t tested may still contain errors that go to production, and again you just hit your new type error instead of the downstream type error. What you need is something that can help you test more paths, and static type checking checks all paths. Further, they can check all paths without writing any tests (you should still have tests, but you need fewer with a static type system to keep your bug rate the same). Moreover, static type checkers catch errors almost immediately, so you get feedback about your errors sooner rather and more frequently, so you spend less time investing in code that will have to be rewritten. Lastly, they put rails on the code—it’s harder to write bad code including gratuitously magical or abstract code, so your coworkers aren’t writing as much bas code that you have to interface with. If you find static type systems to be frustrating, you’re probably the problematic coworker. :)
  - blackrock 6y ago
    I don’t disagree with you. Python seems to encourage poor development practices. Basically, anything goes. This can be problematic if you use other people’s libraries, and if their libraries are not fully vetted. This is not a Python problem, per se. It is a developer problem. It is a human problem. However, with your own code and libraries, you can enforce your own rigor. Keep your functions smaller, test all the inputs, and validate all the outputs. Although you may end up with smaller production code, but more unit tests. The unit tests are good, as they give you evidence that you did cover those corner cases. However, the good thing, is that if the functions are smaller, and well unit tested, then it becomes rare that you have to modify it at a later date. And especially if you think through all the different angles, and try to future proof it. Now you have the ability to do functional composition. Just keep chaining the outputs of one function into another.

gfodor 6y ago

well, sure. certainly one of the costs of a dynamic language is the possibility of typing bugs, and those will likely grow linearly with the size of the code base. the question is if those programs were written in statically typed languages, how the world would differ, in-full. for example, they may have been built faster or sloer. or they may have better or worse test coverage, affecting severe defect count overall. or you may have had to hire a different team, with tradeoffs. hard to say.