6 ms·

So is it simply a standardized comment then? I will have a really bad time convincing my team mates, if that's the case. It's especially bad because, like any

by the_af 5y ago

So is it simply a standardized comment then? I will have a really bad time convincing my team mates, if that's the case. It's especially bad because, like any comment, it can say one thing but the code may do something different (actually happened to me).

zokier 5y ago
yes, and yes. and they are still useful.
rglullis 5y ago
You can have mypy doing the type checking. Just put it on your CI pipeline alongside your tests.
- the_af 5y ago
  I know because I tried setting it up. It's slow, requires too much babysitting, and fails to catch cases. In my experience, it just doesn't work cleanly out of the box like in true statically typed languages, and so I get pushback from my coworkers, who simply can't see the point. And I can't blame them.
  - rglullis 5y ago
    Do your co-workers also only see the point of automated testing if you have 100% coverage? If you/your team want to use a statically typed language, then use one. Python is not it.
    - the_af 5y ago
      You get me wrong: my coworkers struggle to see the point of testing at all. Usually they can be sold on the path of maximum-reward-for-minimum-effort. Hard to enforce/check type hints are not it (they seem like busywork for no actual payoff). With statically typed languages, the ROI would be different: they would either get the thing to compile, or they wouldn't and leave the job. This sounds drastic but it's really not: outside the realm of purist conversations between fans of programming languages, people just want to do their job and get it over with. If the tooling is convoluted, has too many rules, or they aren't forced to use it ("...or else"), they just won't. This is a javascript/python shop, by the way. We cannot choose the languages. We can improve the tooling and train the team with better practices though. > If you/your team want to use a statically typed language, then use one. Python is not it. This is a bit of a cop out though, isn't it? A response to criticism of a (possibly) flawed language feature cannot really be "well, use another language". How else will the language improve then?
      - TillE 5y ago
        Your criticism was: > it just doesn't work cleanly out of the box like in true statically typed languages So the response is entirely appropriate. Python is not a statically typed language, of course type hints don't make it behave exactly like a statically typed language.
        the_af 5y ago
        Fair enough. I can see how my statement was not very clear. I meant to say this: because Python's type hints don't work as well as true statically typed languages (based on my own experience), this makes them less useful and also makes them feel more like busywork. Because of this, my coworkers (who have no experience with statically typed languages either, and tend to dislike best practices and features unless they see a clear return of value from them) are hard to convince type hints are worth the time to learn and use them. Also, let me restate we cannot pick the language. We can just make better or worse use of it.
      - rglullis 5y ago
        > How else will the language improve then? That question hides the assumption that static languages are always an improvement over dynamic ones, when in reality we should think as different species that have adapted to fit into different environments. > We can improve the tooling and train the team with better practices though. "Better practices" are what makes you team more productive, not just blindly copying what other people are doing. If your colleagues really believe that automated tests/type checking are not worth the effort, you are not going to convince them by saying "but so-and-so said otherwise". What you can do is ask for their pain points, and see if the tooling can help with it. You can look at your past burn charts and say "look at this bug here, what caused and why did it take so long to fix? Is this the type of problem that would be easier to solve with static analysis of the code? Look at this refactor that we are planning for next quarter, should we try to increase the test coverage to make sure we have more confidence in the changes?"
        the_af 5y ago
        > That question hides the assumption that static languages are always an improvement over dynamic ones, when in reality we should think as different species that have adapted to fit into different environments. Let me give you a twofold answer to this. 1. I do think statically typed languages are generally better than dynamic languages for most use cases (with a few exceptions). I don't expect to convince you or anyone else of this. It may even be the case that I'm mistaken about this, but I made my mind after years of experience with both kinds of languages. 2. The alleged hidden assumption is not truly important. One should always criticize flawed features of any language, static or dynamic, and the answer should never be "well, choose another language". How else will languages improve if nobody is working on addressing their pain points? > "Better practices" are what makes you team more productive, not just blindly copying what other people are doing. If your colleagues really believe that automated tests/type checking are not worth the effort, you are not going to convince them by saying "but so-and-so said otherwise". What you can do is ask for their pain points, and see if the tooling can help with it. I'm both nodding in agreement and finding it very hard to think of something I said that made you think I disagreed with this.
xarope 5y ago
it's a comment which can trigger an action (if you run mypy). So, unlike a comment, which does nothing, if you run mypy and get some warnings, you can then do something about it (whether it's just # type: ignore or you realise you made a mistake with allocating to variable new_value versus newvalue/new_valu/etc) (btw, in case someone objects, some comments DO do something, e.g. golang's godoc examples)
- the_af 5y ago
  Now I'm confused because the root comment I was replying to asserted that type hints are for documenting, not for checking. If they are for checking, then my other opinion stands: that they are not very good at it (compared to my experience with statically typed languages, even with Typescript!).
  - dragonwriter 5y ago
    They are for documenting and checking. Obviously, if static typing is your only concern, you wouldn't have picked Python to start with, but if you did have a reason to pick Python, you can get a large subset of the value of static typing for correctness and dev-tine information via Python’s support for type hints and the typecheckers (mypy keeps getting pointed to, but it's not the only one) that support it.
    - the_af 5y ago
      Yes, obviously. There are outside factors why Python was chosen. I tend to work with whatever language is needed, and try to make the best of it. I've tried mypy and pytype, and found both to be unsatisfying and hard to sell to the team (which as I mentioned, don't even like writing tests). If you're thinking "well, that's a culture/professionalism rather than a technical problem", you are absolutely right! But I'm left wondering if a language that was better at static typing would be better because, a- the checking would be mandatory, and b- it would be demonstrably more effective than Python's "optional" checking/hinting. At least it'd remove one variable from the problem. Or maybe not, who knows.
dragonwriter 5y ago
> So is it simply a standardized comment then? I will have a really bad time convincing my team mates, if that's the case. If your team doesn't understand the value of things that are essentially standardized comments exposed through the IDE (even if it wasn't for validation, which is also available with IDE integration), you have very bad teammates.
- the_af 5y ago
  As I said in another reply to a comment of yours: maybe so. I cannot do anything about my team mates, but I can push for tools that make the upside of their usage more evident. "Standardized comments", when working with inexperienced/resistant team mates, is not such obviously good tool. In my opinion, of course.

by the_af 5y ago

zokier 5y ago

yes, and yes. and they are still useful.

rglullis 5y ago

You can have mypy doing the type checking. Just put it on your CI pipeline alongside your tests.

the_af 5y ago
I know because I tried setting it up. It's slow, requires too much babysitting, and fails to catch cases. In my experience, it just doesn't work cleanly out of the box like in true statically typed languages, and so I get pushback from my coworkers, who simply can't see the point. And I can't blame them.
- rglullis 5y ago
  Do your co-workers also only see the point of automated testing if you have 100% coverage? If you/your team want to use a statically typed language, then use one. Python is not it.
  - the_af 5y ago
    You get me wrong: my coworkers struggle to see the point of testing at all. Usually they can be sold on the path of maximum-reward-for-minimum-effort. Hard to enforce/check type hints are not it (they seem like busywork for no actual payoff). With statically typed languages, the ROI would be different: they would either get the thing to compile, or they wouldn't and leave the job. This sounds drastic but it's really not: outside the realm of purist conversations between fans of programming languages, people just want to do their job and get it over with. If the tooling is convoluted, has too many rules, or they aren't forced to use it ("...or else"), they just won't. This is a javascript/python shop, by the way. We cannot choose the languages. We can improve the tooling and train the team with better practices though. > If you/your team want to use a statically typed language, then use one. Python is not it. This is a bit of a cop out though, isn't it? A response to criticism of a (possibly) flawed language feature cannot really be "well, use another language". How else will the language improve then?
    - TillE 5y ago
      Your criticism was: > it just doesn't work cleanly out of the box like in true statically typed languages So the response is entirely appropriate. Python is not a statically typed language, of course type hints don't make it behave exactly like a statically typed language.
      - the_af 5y ago
        Fair enough. I can see how my statement was not very clear. I meant to say this: because Python's type hints don't work as well as true statically typed languages (based on my own experience), this makes them less useful and also makes them feel more like busywork. Because of this, my coworkers (who have no experience with statically typed languages either, and tend to dislike best practices and features unless they see a clear return of value from them) are hard to convince type hints are worth the time to learn and use them. Also, let me restate we cannot pick the language. We can just make better or worse use of it.
    - rglullis 5y ago
      > How else will the language improve then? That question hides the assumption that static languages are always an improvement over dynamic ones, when in reality we should think as different species that have adapted to fit into different environments. > We can improve the tooling and train the team with better practices though. "Better practices" are what makes you team more productive, not just blindly copying what other people are doing. If your colleagues really believe that automated tests/type checking are not worth the effort, you are not going to convince them by saying "but so-and-so said otherwise". What you can do is ask for their pain points, and see if the tooling can help with it. You can look at your past burn charts and say "look at this bug here, what caused and why did it take so long to fix? Is this the type of problem that would be easier to solve with static analysis of the code? Look at this refactor that we are planning for next quarter, should we try to increase the test coverage to make sure we have more confidence in the changes?"
      - the_af 5y ago
        > That question hides the assumption that static languages are always an improvement over dynamic ones, when in reality we should think as different species that have adapted to fit into different environments. Let me give you a twofold answer to this. 1. I do think statically typed languages are generally better than dynamic languages for most use cases (with a few exceptions). I don't expect to convince you or anyone else of this. It may even be the case that I'm mistaken about this, but I made my mind after years of experience with both kinds of languages. 2. The alleged hidden assumption is not truly important. One should always criticize flawed features of any language, static or dynamic, and the answer should never be "well, choose another language". How else will languages improve if nobody is working on addressing their pain points? > "Better practices" are what makes you team more productive, not just blindly copying what other people are doing. If your colleagues really believe that automated tests/type checking are not worth the effort, you are not going to convince them by saying "but so-and-so said otherwise". What you can do is ask for their pain points, and see if the tooling can help with it. I'm both nodding in agreement and finding it very hard to think of something I said that made you think I disagreed with this.

xarope 5y ago

it's a comment which can trigger an action (if you run mypy). So, unlike a comment, which does nothing, if you run mypy and get some warnings, you can then do something about it (whether it's just # type: ignore or you realise you made a mistake with allocating to variable new_value versus newvalue/new_valu/etc) (btw, in case someone objects, some comments DO do something, e.g. golang's godoc examples)

the_af 5y ago
Now I'm confused because the root comment I was replying to asserted that type hints are for documenting, not for checking. If they are for checking, then my other opinion stands: that they are not very good at it (compared to my experience with statically typed languages, even with Typescript!).
- dragonwriter 5y ago
  They are for documenting and checking. Obviously, if static typing is your only concern, you wouldn't have picked Python to start with, but if you did have a reason to pick Python, you can get a large subset of the value of static typing for correctness and dev-tine information via Python’s support for type hints and the typecheckers (mypy keeps getting pointed to, but it's not the only one) that support it.
  - the_af 5y ago
    Yes, obviously. There are outside factors why Python was chosen. I tend to work with whatever language is needed, and try to make the best of it. I've tried mypy and pytype, and found both to be unsatisfying and hard to sell to the team (which as I mentioned, don't even like writing tests). If you're thinking "well, that's a culture/professionalism rather than a technical problem", you are absolutely right! But I'm left wondering if a language that was better at static typing would be better because, a- the checking would be mandatory, and b- it would be demonstrably more effective than Python's "optional" checking/hinting. At least it'd remove one variable from the problem. Or maybe not, who knows.

dragonwriter 5y ago

> So is it simply a standardized comment then? I will have a really bad time convincing my team mates, if that's the case. If your team doesn't understand the value of things that are essentially standardized comments exposed through the IDE (even if it wasn't for validation, which is also available with IDE integration), you have very bad teammates.

the_af 5y ago
As I said in another reply to a comment of yours: maybe so. I cannot do anything about my team mates, but I can push for tools that make the upside of their usage more evident. "Standardized comments", when working with inexperienced/resistant team mates, is not such obviously good tool. In my opinion, of course.