3 ms·

Most often in imdustry, you have to begin any complex project without a deep understanding of your domain values, because that understanding only comes iterativ

Most often in imdustry, you have to begin any complex project without a deep understanding of your domain values, because that understanding only comes iteratively. In my experience, the biggest drawback of static typing is that it forces you to design your types when you still don't have enough knowledge, and changing it later is painful.

grumdan 7y ago
I find static types useful for gaining that understanding. It's very helpful to clear up confusion in my head to start prototyping by writing down type definitions and functions' type signatures without implementations before starting to write the actual code. Of course, this only works with a language where the type system is sufficiently painless and allows for such experimentation without a ton of boilerplate (i.e. the language is not Java).
- danmaz74 7y ago
  When I was using c++, the pain came when I discovered that I had to refactor my types because of some cases I didnt know about... Maybe that's easier with more modern statically typed languages.
DonaldPShimoda 7y ago
> In my experience, the biggest drawback of static typing is that it forces you to design your types when you still don't have enough knowledge, and changing it later is painful. I 100% understand where you're coming from, but I view this as an advantage of static type systems. The "pain" is you having to go through your code and make sure that you change your usages of given types to match the new definitions, right? This is forcing you to make sure your code is still correct with respect to the types. Most dynamically-typed languages let you skip this part, but this causes you to lose clarity. Is your old code still correct? Or is it just mostly correct? Are there new unexpected edge cases being introduced that you didn't bother to go check on due to faulty now-outdated assumptions? Changing your types is a pain, I agree. But programs are just about data transformations, and types are representations of the shape of those data. Changing your types without changing every part of your program that touches those types inherently means that your program is now running on invalid assumptions. Sometimes it works fine, but I think it is better to know it's fine than to just say "Well, it seems to work in most cases."
- danmaz74 7y ago
  The risk you describe is real, but good testing coverage lowers it in a way that I find way more efficient than static type checking. When I have that good coverage - which for me means the full pyramid of testing, not just unit tests - I almost never find that problem. Refactoring when you change your understanding of the domain can be a lot of work also when you have dynamic typing and lots of tests, but if the tests are well designed, I rarely feel that as painful as it was when I felt I was battling with the type system. PS: my main experience with static typing was with c++, it's possible that more modern type systems could have improved the situation.

grumdan 7y ago

I find static types useful for gaining that understanding. It's very helpful to clear up confusion in my head to start prototyping by writing down type definitions and functions' type signatures without implementations before starting to write the actual code. Of course, this only works with a language where the type system is sufficiently painless and allows for such experimentation without a ton of boilerplate (i.e. the language is not Java).

danmaz74 7y ago
When I was using c++, the pain came when I discovered that I had to refactor my types because of some cases I didnt know about... Maybe that's easier with more modern statically typed languages.

DonaldPShimoda 7y ago

> In my experience, the biggest drawback of static typing is that it forces you to design your types when you still don't have enough knowledge, and changing it later is painful. I 100% understand where you're coming from, but I view this as an advantage of static type systems. The "pain" is you having to go through your code and make sure that you change your usages of given types to match the new definitions, right? This is forcing you to make sure your code is still correct with respect to the types. Most dynamically-typed languages let you skip this part, but this causes you to lose clarity. Is your old code still correct? Or is it just mostly correct? Are there new unexpected edge cases being introduced that you didn't bother to go check on due to faulty now-outdated assumptions? Changing your types is a pain, I agree. But programs are just about data transformations, and types are representations of the shape of those data. Changing your types without changing every part of your program that touches those types inherently means that your program is now running on invalid assumptions. Sometimes it works fine, but I think it is better to know it's fine than to just say "Well, it seems to work in most cases."

danmaz74 7y ago
The risk you describe is real, but good testing coverage lowers it in a way that I find way more efficient than static type checking. When I have that good coverage - which for me means the full pyramid of testing, not just unit tests - I almost never find that problem. Refactoring when you change your understanding of the domain can be a lot of work also when you have dynamic typing and lots of tests, but if the tests are well designed, I rarely feel that as painful as it was when I felt I was battling with the type system. PS: my main experience with static typing was with c++, it's possible that more modern type systems could have improved the situation.