6 ms·

This is a naive realization. When type checking is used to the maximum extent they become as just as important as unit testing. It is an actual safety contribut

This is a naive realization. When type checking is used to the maximum extent they become as just as important as unit testing. It is an actual safety contribution to the code. Many old school python developers don't realize how important typing actually is. It's not just documentation. It can actually roughly reduce dev time by 50% and increase safety by roughly 2x.

MangoToupe 1y ago
Static type checking (which is what I assume you mean by "typing") can also be a massive pain in the ass that stands in the way of incremental development, even if the end-goal is to ship an api with clear type signatures. There are developers who design apis by trying to figure out readable invocations. These developers discover, rather than design, type hierarchies and library interfaces. > Many old school python developers don't realize how important typing actually is. I don't think this is true. There's simply a communication breakdown where type-first developers don't see the benefits of disabling static checking to design interfaces, and interface-first developers don't see why they should put static checking ahead of interface iteration speed.
- ninetyninenine 1y ago
  >There are developers who design apis by trying to figure out readable invocations. These developers discover, rather than design, type hierarchies and library interfaces. No, you're one of the old school python developers. Types don't hinder creativity, they augment it. The downside is the slight annoyance of updating a type definition and the run time definition vs. just updating the runtime definition. Let me give you an example of how it hinders creativity. Let's say you have a interface that is immensely complex. Many nested structures thousands of keys, and let's say you want to change the design by shifting 3 or 4 things around. Let's also say this interface is utilized by hundreds of other methods and functions. When you move 3 or 4 things around in a complex interface you're going to break a subset of those hundreds of other methods or functions. You're not going to know where they break if you don't have type checking enabled. You're only going to know if you tediously check every single method/function OR if it crashes during runtime. With a statically typed definition you can do that change and the type checker will identify EVERY single place where an additional change to the methods that use that type needs to be changed as well. This allows you to be creative and make any willy nilly changes you want because you are confident that ANY change will be caught by the type checker. This Speeds up creativity, while without it, you will be slowed down, and even afraid to make the breaking change. You are basically the stereotype I described. An old school python developer. Likely one who got used to programming without types and now hasn't utilized types extensively enough to see the benefit. >I don't think this is true. There's simply a communication breakdown where type-first developers don't see the benefits of disabling static checking to design interfaces, and interface-first developers don't see why they should put static checking ahead of interface iteration speed. This is true. You're it. You just don't know it. When I say these developers don't know I'm literally saying they think like you and believe the same things you believe BECAUSE they lack knowledge and have bad habits. The habit thing is what causes the warped knowledge. You're actually slowed down by types because you're not used to it as you spent years coding in python without types so it's ingrained for you to test and think without types. Adding additional types becomes a bit of a initial overhead for these types of people because their programming style is so entrenched. Once you get used to it and once you see that it's really just a slight additional effort, than you will get it. But it takes a bit of discipline and practice to get there.
- watwut 1y ago
  > Static type checking (which is what I assume you mean by "typing") can also be a massive pain in the ass that stands in the way of incremental development, No they dont. There is nothing about types that would make incremental develpment harder. They keep having the same benefits when being incremental.
  - MangoToupe 1y ago
    > There is nothing about types that would make incremental develpment harder. Oh, please, this is either lack of imagination or lack of effort to think. You've never wanted to test a subset of a library halfway through a refactor?
    - loglog 1y ago
      Yes, type checkers are very good at tracking refactoring progress. If it turns out that you can proceed to test some subset, then congratulations, you found a new submodule.
      - MangoToupe 1y ago
        I am continually astounded by the stubborn incuriosity of humans with a bone to pick.
        ninetyninenine 1y ago
        What in the world are you talking about. Please specify how lack of types helped you in your aforementioned scenario. I don't think it's a lack of curiosity from others. But it's more like fundamental lack of knowledge from you. Let's hear it. What is it are you actually talking about? Testing a subset of a library halfway though a refactor? How does a lack of types help with that?
- jampekka 1y ago
  > There are developers who design apis by trying to figure out readable invocations. These developers discover, rather than design, type hierarchies and library interfaces. My hunch is that the people who see no downsides whatsoever in static typing are those who mostly just consume APIs.
  - ninetyninenine 1y ago
    There are downsides. But the upsides outweigh the downsides. I'm not a consumer of APIs. I've done game programming, robotics, embedded system development (with C++ and rust), (web development frontend with react/without react, with jquery, with angurar, with typescript, with js, zod) (web development backend with golang, haskell, nodejs typescript, and lots and lots of python with many of the most popular frameworks with flask + sqlalchemy, django, FastApi + pydantic, ) I've done a lot. I can tell you. If you don't see how types outweigh untyped languages, you're a programmer with experience heavily weighed toward untyped programming. You don't have balanced experience to make a good judgement. Usually these people have a "data scientist" background. Data analyst or data scientist or machine learning engineers... etc. These guys start programing heavily in the python world WITHOUT types and they develop unbalanced opinions shaped by their initial styles of programming. If this describes you, then stop and think... I'm probably right.
    - jampekka 1y ago
      You are wrong. I learned programming mostly in C++ in the late 90's, and programmed in C, C++ and Java in professional settings for a decade or so, and still do from time to time.
      - ninetyninenine 1y ago
        Hm if you want or have time, can you give me a specific example of where no types are clearly superior to types? Maybe you can convince me but I still think your opinion is wrong despite your relevant experience.
simonw 1y ago
It's claims like that which used to put me off embracing type hints! I'd been programming for 20+ years and I genuinely couldn't think of any situations where I'd had a non-trivial bug that I could have avoided if I'd had a type checker - claims like "reduce dev time by 50%" didn't feel credible to me, so I stuck with my previous development habits. Those habits involved a lot of work performed interactively first - using the Python terminal, Jupyter notebooks, the Firefox/Chrome developer tools console. Maybe that's why I never felt like types were saving me any time (and in fact were slowing me down). Then I had my "they're just interactive documentation" realization and finally they started to click for me.
- IshKebab 1y ago
  It depends on the project. If you're working always on one project and you have all the time in the world to learn it (or maybe you wrote it), then you can get away with dynamic types. It's still worse but possible. But if you aren't familiar with a project then dynamic typing makes it an order of magnitude harder to navigate and understand. I tried to contribute some features to a couple of big projects - VSCode and Gitlab. VSCode, very easy. I could follow the flow trivially, just click stuff to go to it etc. Where abstract interfaces are used it's a little more annoying but overall wasn't hard and I have contributed a few features & fixes. Gitlab, absolutely no chance. It's full of magically generated identifiers so even grepping doesn't work. If you find a method like `foo_bar` it's literally impossible to find where it is called without being familiar with the entire codebase (or asking someone who is) and therefore knowing that there's a text file somewhere called `foo.csv` that lists `bar` and the method name is generated from that (or whatever). In VSCode it was literally right-click->find all references. I have yet to succeed in modifying Gitlab at all. I did contribute some features to gitlab-runner, but again that is written in Go so it is possible. So in some cases those claims are not an exaggeration - static types take you from "I give up" to "not too hard".
  - 1313ed01 1y ago
    > In VSCode it was literally right-click->find all references. Flip side of this is that I hate trying to read code written by teams relying heavily on such features, since typically zero time was spent on neatly organizing the code and naming things to make it actually readable (from top to bottom) or grep-able. Things are randomly spread out in tiny files over countless directories and it's a maze you stumble around just clicking identifiers to jump somewhere. Where something is rarely matter as the IDE will find it. I never develop any kind of mental image of that style of code and it completely rules out casually browsing the code using simpler tools.
JimDabell 1y ago
> It can actually roughly reduce dev time by 50% and increase safety by roughly 2x. Type annotations don’t double productivity. What does “increase safety by 2×” even mean? What metric are you tracking there? In my experience, the main non-documentation benefit of type annotations is warning where the code is assuming a value where None might be present. Mixing up any other kind of types is an extremely rare scenario, but NoneType gets everywhere if you let it.
- ninetyninenine 1y ago
  >Type annotations don’t double productivity. What does “increase safety by 2×” even mean? What metric are you tracking there? My own anecdotal metric. Isn't that obvious? The initial post was an anecdotal opinion as well. I don't see a problem here. >In my experience, the main non-documentation benefit of type annotations is warning where the code is assuming a value where None might be present. Mixing up any other kind of types is an extremely rare scenario, but NoneType gets everywhere if you let it. It's not just None. Imagine some highly complex object with nested values and you have some function like this: def modify_direction(direction_object) -> ... wtf is direction object? Is it in Cartesian or is it in polar? Is in 2D or 3D? Most old school python devs literally have to find where modify_direction is called and they find this: def modify_data(data) -> ... ... modify_direction(data.quat) Ok then you have to find where modify data is called, and so on and so forth until you get to here: def combind_data(quat) -> ... def create_quat() -> quat And then boom you figure out what it does by actually reading all the complex quaternion math create_quat does. Absolutely insane. If I have a type, I can just look at the type to figure everything out... you can see how much faster it is. Oh and get this. Let's say there's someone who feels euler angles are better. So he changes create_quat to create_euler. He modifies all the places create_quat is used (which is about 40 places) and he misses 3 or 4 places where it's called. He then ships it to production. Boom The extra time debugging production when it crashes, ans also extra time tediously finding where create_quat was used. All of that could have been saved by a type checker. I'm a big python guy. But I'm also big into haskell. So I know both the typing worlds and the untyped worlds really well. Most people who complain like you literally have mostly come from a python background where typing isn't used much. Maybe you used types occasionally but not in a big way. If you used both untyped languages and typed languages extensively you will know that types are intrinsically better. It's not even a contest. Anyone who still debates this stuff just lacks experience.

MangoToupe 1y ago

Static type checking (which is what I assume you mean by "typing") can also be a massive pain in the ass that stands in the way of incremental development, even if the end-goal is to ship an api with clear type signatures. There are developers who design apis by trying to figure out readable invocations. These developers discover, rather than design, type hierarchies and library interfaces. > Many old school python developers don't realize how important typing actually is. I don't think this is true. There's simply a communication breakdown where type-first developers don't see the benefits of disabling static checking to design interfaces, and interface-first developers don't see why they should put static checking ahead of interface iteration speed.

ninetyninenine 1y ago
>There are developers who design apis by trying to figure out readable invocations. These developers discover, rather than design, type hierarchies and library interfaces. No, you're one of the old school python developers. Types don't hinder creativity, they augment it. The downside is the slight annoyance of updating a type definition and the run time definition vs. just updating the runtime definition. Let me give you an example of how it hinders creativity. Let's say you have a interface that is immensely complex. Many nested structures thousands of keys, and let's say you want to change the design by shifting 3 or 4 things around. Let's also say this interface is utilized by hundreds of other methods and functions. When you move 3 or 4 things around in a complex interface you're going to break a subset of those hundreds of other methods or functions. You're not going to know where they break if you don't have type checking enabled. You're only going to know if you tediously check every single method/function OR if it crashes during runtime. With a statically typed definition you can do that change and the type checker will identify EVERY single place where an additional change to the methods that use that type needs to be changed as well. This allows you to be creative and make any willy nilly changes you want because you are confident that ANY change will be caught by the type checker. This Speeds up creativity, while without it, you will be slowed down, and even afraid to make the breaking change. You are basically the stereotype I described. An old school python developer. Likely one who got used to programming without types and now hasn't utilized types extensively enough to see the benefit. >I don't think this is true. There's simply a communication breakdown where type-first developers don't see the benefits of disabling static checking to design interfaces, and interface-first developers don't see why they should put static checking ahead of interface iteration speed. This is true. You're it. You just don't know it. When I say these developers don't know I'm literally saying they think like you and believe the same things you believe BECAUSE they lack knowledge and have bad habits. The habit thing is what causes the warped knowledge. You're actually slowed down by types because you're not used to it as you spent years coding in python without types so it's ingrained for you to test and think without types. Adding additional types becomes a bit of a initial overhead for these types of people because their programming style is so entrenched. Once you get used to it and once you see that it's really just a slight additional effort, than you will get it. But it takes a bit of discipline and practice to get there.
watwut 1y ago
> Static type checking (which is what I assume you mean by "typing") can also be a massive pain in the ass that stands in the way of incremental development, No they dont. There is nothing about types that would make incremental develpment harder. They keep having the same benefits when being incremental.
- MangoToupe 1y ago
  > There is nothing about types that would make incremental develpment harder. Oh, please, this is either lack of imagination or lack of effort to think. You've never wanted to test a subset of a library halfway through a refactor?
  - loglog 1y ago
    Yes, type checkers are very good at tracking refactoring progress. If it turns out that you can proceed to test some subset, then congratulations, you found a new submodule.
    - MangoToupe 1y ago
      I am continually astounded by the stubborn incuriosity of humans with a bone to pick.
      - ninetyninenine 1y ago
        What in the world are you talking about. Please specify how lack of types helped you in your aforementioned scenario. I don't think it's a lack of curiosity from others. But it's more like fundamental lack of knowledge from you. Let's hear it. What is it are you actually talking about? Testing a subset of a library halfway though a refactor? How does a lack of types help with that?
jampekka 1y ago
> There are developers who design apis by trying to figure out readable invocations. These developers discover, rather than design, type hierarchies and library interfaces. My hunch is that the people who see no downsides whatsoever in static typing are those who mostly just consume APIs.
- ninetyninenine 1y ago
  There are downsides. But the upsides outweigh the downsides. I'm not a consumer of APIs. I've done game programming, robotics, embedded system development (with C++ and rust), (web development frontend with react/without react, with jquery, with angurar, with typescript, with js, zod) (web development backend with golang, haskell, nodejs typescript, and lots and lots of python with many of the most popular frameworks with flask + sqlalchemy, django, FastApi + pydantic, ) I've done a lot. I can tell you. If you don't see how types outweigh untyped languages, you're a programmer with experience heavily weighed toward untyped programming. You don't have balanced experience to make a good judgement. Usually these people have a "data scientist" background. Data analyst or data scientist or machine learning engineers... etc. These guys start programing heavily in the python world WITHOUT types and they develop unbalanced opinions shaped by their initial styles of programming. If this describes you, then stop and think... I'm probably right.
  - jampekka 1y ago
    You are wrong. I learned programming mostly in C++ in the late 90's, and programmed in C, C++ and Java in professional settings for a decade or so, and still do from time to time.
    - ninetyninenine 1y ago
      Hm if you want or have time, can you give me a specific example of where no types are clearly superior to types? Maybe you can convince me but I still think your opinion is wrong despite your relevant experience.

simonw 1y ago

It's claims like that which used to put me off embracing type hints! I'd been programming for 20+ years and I genuinely couldn't think of any situations where I'd had a non-trivial bug that I could have avoided if I'd had a type checker - claims like "reduce dev time by 50%" didn't feel credible to me, so I stuck with my previous development habits. Those habits involved a lot of work performed interactively first - using the Python terminal, Jupyter notebooks, the Firefox/Chrome developer tools console. Maybe that's why I never felt like types were saving me any time (and in fact were slowing me down). Then I had my "they're just interactive documentation" realization and finally they started to click for me.

IshKebab 1y ago
It depends on the project. If you're working always on one project and you have all the time in the world to learn it (or maybe you wrote it), then you can get away with dynamic types. It's still worse but possible. But if you aren't familiar with a project then dynamic typing makes it an order of magnitude harder to navigate and understand. I tried to contribute some features to a couple of big projects - VSCode and Gitlab. VSCode, very easy. I could follow the flow trivially, just click stuff to go to it etc. Where abstract interfaces are used it's a little more annoying but overall wasn't hard and I have contributed a few features & fixes. Gitlab, absolutely no chance. It's full of magically generated identifiers so even grepping doesn't work. If you find a method like `foo_bar` it's literally impossible to find where it is called without being familiar with the entire codebase (or asking someone who is) and therefore knowing that there's a text file somewhere called `foo.csv` that lists `bar` and the method name is generated from that (or whatever). In VSCode it was literally right-click->find all references. I have yet to succeed in modifying Gitlab at all. I did contribute some features to gitlab-runner, but again that is written in Go so it is possible. So in some cases those claims are not an exaggeration - static types take you from "I give up" to "not too hard".
- 1313ed01 1y ago
  > In VSCode it was literally right-click->find all references. Flip side of this is that I hate trying to read code written by teams relying heavily on such features, since typically zero time was spent on neatly organizing the code and naming things to make it actually readable (from top to bottom) or grep-able. Things are randomly spread out in tiny files over countless directories and it's a maze you stumble around just clicking identifiers to jump somewhere. Where something is rarely matter as the IDE will find it. I never develop any kind of mental image of that style of code and it completely rules out casually browsing the code using simpler tools.

JimDabell 1y ago

> It can actually roughly reduce dev time by 50% and increase safety by roughly 2x. Type annotations don’t double productivity. What does “increase safety by 2×” even mean? What metric are you tracking there? In my experience, the main non-documentation benefit of type annotations is warning where the code is assuming a value where None might be present. Mixing up any other kind of types is an extremely rare scenario, but NoneType gets everywhere if you let it.

ninetyninenine 1y ago
>Type annotations don’t double productivity. What does “increase safety by 2×” even mean? What metric are you tracking there? My own anecdotal metric. Isn't that obvious? The initial post was an anecdotal opinion as well. I don't see a problem here. >In my experience, the main non-documentation benefit of type annotations is warning where the code is assuming a value where None might be present. Mixing up any other kind of types is an extremely rare scenario, but NoneType gets everywhere if you let it. It's not just None. Imagine some highly complex object with nested values and you have some function like this: def modify_direction(direction_object) -> ... wtf is direction object? Is it in Cartesian or is it in polar? Is in 2D or 3D? Most old school python devs literally have to find where modify_direction is called and they find this: def modify_data(data) -> ... ... modify_direction(data.quat) Ok then you have to find where modify data is called, and so on and so forth until you get to here: def combind_data(quat) -> ... def create_quat() -> quat And then boom you figure out what it does by actually reading all the complex quaternion math create_quat does. Absolutely insane. If I have a type, I can just look at the type to figure everything out... you can see how much faster it is. Oh and get this. Let's say there's someone who feels euler angles are better. So he changes create_quat to create_euler. He modifies all the places create_quat is used (which is about 40 places) and he misses 3 or 4 places where it's called. He then ships it to production. Boom The extra time debugging production when it crashes, ans also extra time tediously finding where create_quat was used. All of that could have been saved by a type checker. I'm a big python guy. But I'm also big into haskell. So I know both the typing worlds and the untyped worlds really well. Most people who complain like you literally have mostly come from a python background where typing isn't used much. Maybe you used types occasionally but not in a big way. If you used both untyped languages and typed languages extensively you will know that types are intrinsically better. It's not even a contest. Anyone who still debates this stuff just lacks experience.