5 ms·

> How else will the language improve then? That question hides the assumption that static languages are always an improvement over dynamic ones, when in realit

> 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.
- rglullis 5y ago
  > generally better than dynamic languages for most use cases Shouldn't then the exercise be to figure out if these use cases are applicable to your situation? What is your team and company optimizing for? > How else will languages improve if nobody is working on addressing their pain points? "See, at my work we need to travel between two islands as fast and cheap as possible. My team is used to high-speed motorboats, but my experience tells me that hydroplanes are faster. I tried putting wings on my motorboats, but it still wasn't as fast. No, we can not buy hydroplanes. No, my team is not licensed to fly. But if no one acknowledges that motorboats are slower, how will they ever be as fast as a hydroplane? And no, I haven't really looked into the fuel costs of planes vs boats..."
  - the_af 5y ago
    Your "islands" anecdote is amusing, if a bit condescending. Do you honestly think it fairly addresses the very direct question I asked you? Also, do you honestly expect me to detail what my team and company is optimizing for here? What for? What does it have to do with Python type hinting?
    - rglullis 5y ago
      The problem I see is that you are trying to peg a square in a round role and thinking that the square is at fault for not being flexible enough. Anyone that has seen the py2 -> py3 debacle will tell you that "let's make python static" is not something that could happen unless you are willing to rewrite the entire ecosystem of libraries and applications, and quite possibly upsetting the majority of current users who were attracted to it in the first place precisely because it is so easy to get started with it. You can not turn Python into a "fully static" language without changing it so much to the point of making into a different beast. And why should others make all this work to fit into your view of what is "best" when you can just use another language in the first place?
      - the_af 5y ago
        I don't want to turn Python into a statically typed language. I think there's valid criticism to be made about the flaws of its type hinting (as does the article's author), and I cannot help but compare its usefulness to static type checking. I also cannot choose the language. I'm not in a position to choose languages at my current job; I seldom find myself in that position at any job.

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.

rglullis 5y ago
> generally better than dynamic languages for most use cases Shouldn't then the exercise be to figure out if these use cases are applicable to your situation? What is your team and company optimizing for? > How else will languages improve if nobody is working on addressing their pain points? "See, at my work we need to travel between two islands as fast and cheap as possible. My team is used to high-speed motorboats, but my experience tells me that hydroplanes are faster. I tried putting wings on my motorboats, but it still wasn't as fast. No, we can not buy hydroplanes. No, my team is not licensed to fly. But if no one acknowledges that motorboats are slower, how will they ever be as fast as a hydroplane? And no, I haven't really looked into the fuel costs of planes vs boats..."
- the_af 5y ago
  Your "islands" anecdote is amusing, if a bit condescending. Do you honestly think it fairly addresses the very direct question I asked you? Also, do you honestly expect me to detail what my team and company is optimizing for here? What for? What does it have to do with Python type hinting?
  - rglullis 5y ago
    The problem I see is that you are trying to peg a square in a round role and thinking that the square is at fault for not being flexible enough. Anyone that has seen the py2 -> py3 debacle will tell you that "let's make python static" is not something that could happen unless you are willing to rewrite the entire ecosystem of libraries and applications, and quite possibly upsetting the majority of current users who were attracted to it in the first place precisely because it is so easy to get started with it. You can not turn Python into a "fully static" language without changing it so much to the point of making into a different beast. And why should others make all this work to fit into your view of what is "best" when you can just use another language in the first place?
    - the_af 5y ago
      I don't want to turn Python into a statically typed language. I think there's valid criticism to be made about the flaws of its type hinting (as does the article's author), and I cannot help but compare its usefulness to static type checking. I also cannot choose the language. I'm not in a position to choose languages at my current job; I seldom find myself in that position at any job.