4 ms·

To each their own. I find almost all functions I write are really designed with one type in mind anyway. One difference may be if you primarily work in your ow

To each their own. I find almost all functions I write are really designed with one type in mind anyway. One difference may be if you primarily work in your own projects or work with other people’s projects. And how skilled the other developers are. In my own projects I instinctively know the types, but not in other projects, and having the types documented allows me to make changes much more quickly.

musingsole 6y ago
> One difference may be if you primarily work in your own projects or work with other people’s projects. Type-advocates throw this around all the time as if it's not the most patronizing thoughtpattern. Yes, I work on a good sized project with another 15 engineers using Python for the backend and angular for the frontend. If scale were going to reveal something dramatically different than whatever toy algorithms you might imagine I'm playing with...it would've happened by now.
- sseagull 6y ago
  I think you took this differently than what I intended, although that is partly my fault. What I meant was more along the lines of “do you regularly jump into the deep end on new projects that were started/maintained by someone else?” Doing that is what made me a believer. Jumping into my current project, taking over from some else, was a nightmare without types. I had no idea if something was a string, a dict, a dataclass, a custom class, etc, with only vague hints based on how it was being used. These obviously had “types”, and the functions were designed for only one set of types. I just couldn’t remember what. “Your own” doesn’t necessarily mean small or toy. But more about consistently working in familiar code bases where you are already familiar with what types are flowing around. I think of these kinds of types as enforced documentation. It’s not for you (necessarily), it’s for other people.

musingsole 6y ago

> One difference may be if you primarily work in your own projects or work with other people’s projects. Type-advocates throw this around all the time as if it's not the most patronizing thoughtpattern. Yes, I work on a good sized project with another 15 engineers using Python for the backend and angular for the frontend. If scale were going to reveal something dramatically different than whatever toy algorithms you might imagine I'm playing with...it would've happened by now.

sseagull 6y ago
I think you took this differently than what I intended, although that is partly my fault. What I meant was more along the lines of “do you regularly jump into the deep end on new projects that were started/maintained by someone else?” Doing that is what made me a believer. Jumping into my current project, taking over from some else, was a nightmare without types. I had no idea if something was a string, a dict, a dataclass, a custom class, etc, with only vague hints based on how it was being used. These obviously had “types”, and the functions were designed for only one set of types. I just couldn’t remember what. “Your own” doesn’t necessarily mean small or toy. But more about consistently working in familiar code bases where you are already familiar with what types are flowing around. I think of these kinds of types as enforced documentation. It’s not for you (necessarily), it’s for other people.