3 ms·

> > So is time you spend thinking about the behavior of the code in your head > You have to do this anyway; static typing doesn't write your code for you. Even

> > So is time you spend thinking about the behavior of the code in your head > You have to do this anyway; static typing doesn't write your code for you. Even Haskell, which I will freely admit is probably the closest thing to an AI that I've ever seen in a programming language, can't do that. :-) I think what he meant to say is that you spent 95% of your time to think about: "what is the kind of think I can from this method call and how can and should I use it and what should I return in the end". Writing down the result of your thoughts takes almost no time in comparison. Not only that, in good statically typed languages, you don't have to write down the types explicitly most of the time (but you can still have your IDE show them to you if you want to see them). And in addition to that, you certainly have to think _less_ in many cases. A good example are functions that return lists. Often you always have an element in the list. Using a good type-system, it will be indicated, so when I get the list, I know that I don't have to handle the case that the list is empty. In python I would often have to think _more_ about it and look into the documentation or maybe even the implementation to understand if it could return an empty list or not.

pdonis 6y ago
> you spent 95% of your time to think about: "what is the kind of think I can from this method call and how can and should I use it and what should I return in the end". Writing down the result of your thoughts takes almost no time in comparison. The issue here isn't static vs. dynamic typing, it's API documentation. In cases where static type declarations work out to be sufficient as API documentation, sure, use them as API documentation. But the "time to think" issue isn't being solved by static typing; it's being solved by having good documentation for the APIs you are using (or writing good documentation for the APIs of the libraries you are writing). > A good example are functions that return lists. Often you always have an element in the list. Using a good type-system, it will be indicated, so when I get the list, I know that I don't have to handle the case that the list is empty. Same comment here: whether or not the function can return an empty list is part of the API. The API needs to be documented somehow. A static type declaration might be enough, or it might not. Either way, what's solving the issue isn't static typing, it's API documentation.
- valenterry 6y ago
  Let me quote your original claim again: > Time you spend writing type specifications is time you're not spending doing something else that might add more value. To what I say: writing out a type (= a few characters) is negligible anyways when compared to the time you spend thinking about what the type is (which you have to do in python as well, maybe even more). > Same comment here: whether or not the function can return an empty list is part of the API. The API needs to be documented somehow. If you have a proper API documentation in both cases, then you have to think less, that's true. In the real world however, I can testify that I have to think longer in python because 1) APIs not always well documented and 2) even if they are, a well documented API that uses statical types is still easier to use due to the automatic compiler/IDE support.
  - pdonis 6y ago
    > writing out a type (= a few characters) is negligible anyways when compared to the time you spend thinking about what the type is Writing out a type is only a few characters if it's a type that's already built into your type system. (In which case, as others have already pointed out, you probably won't have to write it anyway in a statically typed language because the type system will automatically infer it. But in such cases, you're not gaining any documentation benefit from it.) If it's a type you're having to invent as part of writing the code, writing it out everywhere it gets used can be a lot more work. > I have to think longer in python because 1) APIs not always well documented Meaning, not well documented compared to APIs in other languages? That hasn't been my experience; my experience has been that API documentation pretty much sucks everywhere. > a well documented API that uses statical types is still easier to use due to the automatic compiler/IDE support If you use an IDE, perhaps. (I don't; I find that they cost me more than they save me.)
    - valenterry 6y ago
      > Writing out a type is only a few characters if it's a type that's already built into your type system. Right, but if it is not, then you also have write extra code in python (e.g. create a new class). Of course alternatively you can also just use "String" for everything (you can do that with a statical typesystem too), but I hope you agree with me that this isn't a great idea in any language. I also have the feeling that you might change your mind if you try out a modern fully fledged IDE with a good statically typed language. The reason why I think this is because of things that you said such as "But in such cases, you're not gaining any documentation benefit from it." which are correct if you are not using an IDE. But if you do, it's actually wrong. IDEs like IntelliJ can be configured to show all (or only certain) types that are not written in text but that the compiler infers - without pressing any key. I like to use this feature a lot when diving into an unknown code base. > Meaning, not well documented compared to APIs in other languages? No, just not being well documented. Many popular libraries in python are well documented, but not all are. And the less popular/public ones are often poorly documented. The same is true for other languages as well, but in those, you at least you often have a "basic" documentation through the types.
pdonis 6y ago
> In python I would often have to think _more_ about it and look into the documentation or maybe even the implementation to understand if it could return an empty list or not. In many cases in Python, you don't have to care. For example, if you're going to iterate over the list, Python will iterate over an empty list just fine: it will execute zero iterations. No need to check anything.
- valenterry 6y ago
  Right. I was referring to the cases where you must care, such as presenting a list of errors to someone or doing a calculation where an empty list must be considered in a special way if it occurs etc.

pdonis 6y ago

> you spent 95% of your time to think about: "what is the kind of think I can from this method call and how can and should I use it and what should I return in the end". Writing down the result of your thoughts takes almost no time in comparison. The issue here isn't static vs. dynamic typing, it's API documentation. In cases where static type declarations work out to be sufficient as API documentation, sure, use them as API documentation. But the "time to think" issue isn't being solved by static typing; it's being solved by having good documentation for the APIs you are using (or writing good documentation for the APIs of the libraries you are writing). > A good example are functions that return lists. Often you always have an element in the list. Using a good type-system, it will be indicated, so when I get the list, I know that I don't have to handle the case that the list is empty. Same comment here: whether or not the function can return an empty list is part of the API. The API needs to be documented somehow. A static type declaration might be enough, or it might not. Either way, what's solving the issue isn't static typing, it's API documentation.

valenterry 6y ago
Let me quote your original claim again: > Time you spend writing type specifications is time you're not spending doing something else that might add more value. To what I say: writing out a type (= a few characters) is negligible anyways when compared to the time you spend thinking about what the type is (which you have to do in python as well, maybe even more). > Same comment here: whether or not the function can return an empty list is part of the API. The API needs to be documented somehow. If you have a proper API documentation in both cases, then you have to think less, that's true. In the real world however, I can testify that I have to think longer in python because 1) APIs not always well documented and 2) even if they are, a well documented API that uses statical types is still easier to use due to the automatic compiler/IDE support.
- pdonis 6y ago
  > writing out a type (= a few characters) is negligible anyways when compared to the time you spend thinking about what the type is Writing out a type is only a few characters if it's a type that's already built into your type system. (In which case, as others have already pointed out, you probably won't have to write it anyway in a statically typed language because the type system will automatically infer it. But in such cases, you're not gaining any documentation benefit from it.) If it's a type you're having to invent as part of writing the code, writing it out everywhere it gets used can be a lot more work. > I have to think longer in python because 1) APIs not always well documented Meaning, not well documented compared to APIs in other languages? That hasn't been my experience; my experience has been that API documentation pretty much sucks everywhere. > a well documented API that uses statical types is still easier to use due to the automatic compiler/IDE support If you use an IDE, perhaps. (I don't; I find that they cost me more than they save me.)
  - valenterry 6y ago
    > Writing out a type is only a few characters if it's a type that's already built into your type system. Right, but if it is not, then you also have write extra code in python (e.g. create a new class). Of course alternatively you can also just use "String" for everything (you can do that with a statical typesystem too), but I hope you agree with me that this isn't a great idea in any language. I also have the feeling that you might change your mind if you try out a modern fully fledged IDE with a good statically typed language. The reason why I think this is because of things that you said such as "But in such cases, you're not gaining any documentation benefit from it." which are correct if you are not using an IDE. But if you do, it's actually wrong. IDEs like IntelliJ can be configured to show all (or only certain) types that are not written in text but that the compiler infers - without pressing any key. I like to use this feature a lot when diving into an unknown code base. > Meaning, not well documented compared to APIs in other languages? No, just not being well documented. Many popular libraries in python are well documented, but not all are. And the less popular/public ones are often poorly documented. The same is true for other languages as well, but in those, you at least you often have a "basic" documentation through the types.

pdonis 6y ago

> In python I would often have to think _more_ about it and look into the documentation or maybe even the implementation to understand if it could return an empty list or not. In many cases in Python, you don't have to care. For example, if you're going to iterate over the list, Python will iterate over an empty list just fine: it will execute zero iterations. No need to check anything.

valenterry 6y ago
Right. I was referring to the cases where you must care, such as presenting a list of errors to someone or doing a calculation where an empty list must be considered in a special way if it occurs etc.